Rate our pivot : PythonAnywhere
2 comments
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.
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.
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.
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.
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?
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.
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.
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?
Does that make sense?
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.
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.
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.
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.
>> 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.
easy to click: http://pythonanywhere.com
Thanks! If anyone could tell us how to make clickable links in ask-HN-style posts, we'd be eternally grateful :-)
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.
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.
http://pythonanywhere.com
The user's code runs in a sandbox, to guard against griefers.
We're not tied to Python - in a later version, the server-side process could be anything, from Ruby to a Bash shell.
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.
Prospective users have requested:
- 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.
- Server-side storage / Integration with Dropbox or Github or other DVCS hosts.
- Shared console sessions, so two or more users can work in the same session, maybe for tutoring, or possibly for remote pairing.
- Providing many different Python versions, all loaded with packages from PyPI, so users could try things out without any local install or config.
- Providing a grid computing API, to run users' code across several of our EC2 instances.
- An editor.
We've just gone live today with a limited private beta, in which multiple users can share persistent sessions.
We'd appreciate any feedback at all, but we're particularly interested in:
- Features that would make it useful to you.
- Features that you would pay for.
- How well we're presenting our case.
Any thoughts would be much appreciated -- thanks in advance!