Rate our pivot : PythonAnywhere • Hacker News Board

Re: Rate our pivot : PythonAnywhere

#11

Post by gpjt » Wed, Apr 27, 2011, 8:42 PM UTC

JoachimSchipper wrote: post #9

tartley wrote: post #5

Earlier quoted context omitted.

Hey. Thanks for the comment. Yep. Right now the beta only works on regular OS & browsers, and on the Nokia N900, but we still have some work to do on Android, and have yet to test on iOS, but theoretically we have no known incompatible tech. We hadn't thought about chart drawing, but it seems to make good sense. Thanks! We're constantly brainstorming about the best ways to import and export source and data. We're cur…

Chart drawing is useful (if only for visually exploring the data). I wouldn't be willing to be tied to your service, so you may want to integrate some standard library? A chroot-like system would work fine, and also make it easy to export data. This also needs a live demo. And have you already figured out how to make the Python interpreter persist across reboots?

Right, we're definitely intending to avoid tying people in as much as possible. matplotlib might be a good choice, perhaps?

PythonAnywhere currently runs in a chroot jail, and we're thinking that we should have a simple URL scheme for accessing files in your private store -- so that, for example, if you're logged in, you could access stuff using something like http://pythonanywhere.com/user/your-id/path/to/your/file. Of course, Dropbox is likely to be more convenient a lot of the time. But we don't want to rely on them entirely.

Re: the live demo -- definitely, once we're in beta we'll put a console on the front page of the site, and signing up for a free account will be really easy.

Making the interpreter persist across reboots (especially with eg. DB connection variables intact) is definitely going to be tricky. We've got ideas, but nothing working yet.

Re: Rate our pivot : PythonAnywhere

#12

Post by wladimir » Thu, Apr 28, 2011, 6:12 AM UTC

gpjt wrote: post #11

JoachimSchipper wrote: post #9

Earlier quoted context omitted.

Chart drawing is useful (if only for visually exploring the data). I wouldn't be willing to be tied to your service, so you may want to integrate some standard library? A chroot-like system would work fine, and also make it easy to export data. This also needs a live demo. And have you already figured out how to make the Python interpreter persist across reboots?

Right, we're definitely intending to avoid tying people in as much as possible. matplotlib might be a good choice, perhaps? PythonAnywhere currently runs in a chroot jail, and we're thinking that we should have a simple URL scheme for accessing files in your private store -- so that, for example, if you're logged in, you could access stuff using something like http://pythonanywhere.com/user/your-id/path/to/your/file…

I agree with the the grandparent that preventing lock-in is important, but I think in addition to the standard you do want to offer some APIs in your service that are specific to the environment you are in (cloud, HTML5). Kind of like AppEngine with their native datastore and Amazon with EBS.

Re: Rate our pivot : PythonAnywhere

#13

Post by gpjt » Thu, Apr 28, 2011, 10:03 AM UTC

wladimir wrote: post #12

gpjt wrote: post #11

Earlier quoted context omitted.

Right, we're definitely intending to avoid tying people in as much as possible. matplotlib might be a good choice, perhaps? PythonAnywhere currently runs in a chroot jail, and we're thinking that we should have a simple URL scheme for accessing files in your private store -- so that, for example, if you're logged in, you could access stuff using something like http://pythonanywhere.com/user/your-id/path/to/your/file…

I agree with the the grandparent that preventing lock-in is important, but I think in addition to the standard you do want to offer some APIs in your service that are specific to the environment you are in (cloud, HTML5). Kind of like AppEngine with their native datastore and Amazon with EBS.

That's an interesting point. I guess the distinction we want to make is between creating private APIs that would lock people in, and enabling them to use appropriate standards and publicly-available modules. So integrating with (say) WebGL for graphics, or making it easy for people to mount their own EBS volumes or access S3 (we're running on AWS anyway) would be good, whereas insisting that the only way to display plots of data was to call our private API would be bad.

Does that make sense?

Re: Rate our pivot : PythonAnywhere

#14

Post by wladimir » Thu, Apr 28, 2011, 12:44 PM UTC

gpjt wrote: post #13

wladimir wrote: post #12

Earlier quoted context omitted.

I agree with the the grandparent that preventing lock-in is important, but I think in addition to the standard you do want to offer some APIs in your service that are specific to the environment you are in (cloud, HTML5). Kind of like AppEngine with their native datastore and Amazon with EBS.

That's an interesting point. I guess the distinction we want to make is between creating private APIs that would lock people in, and enabling them to use appropriate standards and publicly-available modules. So integrating with (say) WebGL for graphics, or making it easy for people to mount their own EBS volumes or access S3 (we're running on AWS anyway) would be good, whereas insisting that the only way to display p…

Yes, exactly. I think it makes sense to use standard modules if possible, but use private APIs for functionality that is not in the standard Python.