

Rate our pivot : PythonAnywhere - tartley

We recently posted a 'Rate our Pivot', for Project Dirigible, our Python-based spreadsheet web-application. (http://news.ycombinator.com/item?id=2304691)<p>We received some great responses and excellent advice. The thing that people found the most interesting was the 'effortless cloud supercomputing' aspect, while being least engaged by the spreadsheet-UI.<p>So we trimmed the application to provide something more focused. The result is PythonAnywhere - a interactive Python console in the browser, that runs your code on our servers.<p>http://pythonanywhere.com<p>The user's code runs in a sandbox, to guard against griefers.<p>We're not tied to Python - in a later version, the server-side process could be anything, from Ruby to a Bash shell.<p>Casual use is free, like Dropbox, and we would charge for more resource-intensive services, maybe access to networking, or for access to substantial CPU time or disk space.<p>Prospective users have requested:<p>- Persistent sessions, so you can close your session but then pick it up from another device later on, with screen content, command-line history, and Python context intact.<p>- Server-side storage / Integration with Dropbox or Github or other DVCS hosts.<p>- Shared console sessions, so two or more users can work in the same session, maybe for tutoring, or possibly for remote pairing.<p>- Providing many different Python versions, all loaded with packages from PyPI, so users could try things out without any local install or config.<p>- Providing a grid computing API, to run users' code across several of our EC2 instances.<p>- An editor.<p>We've just gone live today with a limited private beta, in which multiple users can share persistent sessions.<p>We'd appreciate any feedback at all, but we're particularly interested in:<p>- Features that would make it useful to you.<p>- Features that you would pay for.<p>- How well we're presenting our case.<p>Any thoughts would be much appreciated -- thanks in advance!
======
wladimir
I think the idea is certainly neat. I guess it's very useful if you need a lot
of bandwidth/CPU power when working from a mobile device.

So the idea is that you provide grid computing support from Python and an in-
the-cloud IDE? Like a "matlab in the cloud"?

In that case, a very important feature would be chart drawing support, and
ways to import/export data.

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

------
iworkforthem
easy to click: <http://pythonanywhere.com>

~~~
gpjt
Thanks! If anyone could tell us how to make clickable links in ask-HN-style
posts, we'd be eternally grateful :-)

~~~
JoachimSchipper
It's impossible, so there's usually a comment like this.

~~~
gpjt
Ah, I see.

