[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.