[tartley]

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 currently thinking about Dropbox or Github integration, or maybe a very lightweight client-end component which simply allows you to sync the current directory to your PythonAnywhere server-side storage.

[JoachimSchipper]

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?

[gpjt]

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.

[wladimir]

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.

[gpjt]

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?

[wladimir]

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.

[wladimir]

Yes some charting/visualization would also be a nice thing to make the intro page less dry.

For example, you could simply interface to one of the HTML5 charting libs such as Highcharts or even pass it through Google Visualisation API.

About the datasets, maybe another idea would be to have some public datasets readily available to hack on.

[tartley]

Our intro page does need some love, good call.

>> HTML5 charting or Google Visualisation

This would be great. Maybe we could have a canvas element off on some discreet pane somewhere, direct these rendering libraries at it, and reveal the pane when the canvas gets written to.

>> public datasets readily available to hack on.

Genius. Great idea.