Skulpt: client side Python without preprocessing | Hacker News Reader

Skulpt: client side Python without preprocessing

skulpt.org

112 pointsgalfarragem47 comments

Many people, especially kids, will at some point encounter an online learning tool where you can just run Python in the browser. Chances are the underlying interpreter is Skulpt. A short list of examples:

- https://pythonroom.com: has a free online curriculum with more helpful error messages that kids can understand and real-time analytics for teachers

- https://trinket.io: handles Python, turtle graphics, and pygal charting in the browser

- https://tynker.com: their Python notebook feature uses Skulpt

- http://interactivepython.org: a popular open-source textbook that has excellent Parson's problems

- http://codeskulptor.org: implements some custom Skulpt libraries that I haven't seen anywhere else

- https://www.coursera.org/learn/interactive-python-1: Coursera's interactive Python course

That's just the ones I could remember off the top of my head. I truly believe this is one of the most impactful open-source projects of all time, especially if you consider the impact is has on kids (i.e. future computer scientists) that can use an excellent teaching language like Python directly in their web browser.

Python dev and trainer here.

Skulp is terrible as a python implementations go. Error reporting is meh. Many advanced features are not supported.

Brython is a much better alternative. More complete and robust.

However, i advise against running a js python in general. Exposing secured and isolated jupyter notebooks is much better for learning.

I think it's important to distinguish user groups. No solution is best for all of them.

For scientists or data analysts, jupyter notebooks are a great choice since they mirror the professional and research tools they'll use.

For web development, an in-browser IDE like Cloud9 would be my choice to get an arbitrary room of adults up to speed.

But for middle or high school audiences, or even adult beginners, solutions like the above are far too complex. It's easy to get a certain expert blindness, but a Jupyter notebook for instance can actually be a huge problem form someone trying to understand flow of control, since you can execute code blocks in an arbitrary order into the same runtime.

Tradeoffs between power and usability abound. Jupyter is a good blend. A full IDE is power. Skulpt prioritizes usability. Some group of users fits into each of these buckets.

So (surprise, surprise!) The meanings of 'best' and 'terrible' are highly dependent upon specific user needs.

> Jupyter notebook for instance can actually be a huge problem form someone trying to understand flow of control, since you can execute code blocks in an arbitrary order into the same runtime.

True. I usually don't let them know they can create several cells first. They use only one for a good part of the show.

Skulpt will lead to strange debugging sessions, and you really, really want them to learn how to debug autonomously asap. So having the same stacktrace in every env is very important.

High School CS teacher here. Repl.it has always done me a treat, I've have had one or two odd bugs but 99% fine and they're adding nice features aimed at education too.

Thanks for mentioning that. I'd never heard of it; playing with it now, and it seems very nice indeed!

I work as an engineer at https://datacamp.com, and we run the code directly on a server, but I've always thought it would be interesting to try building interactive programming exercises with Skulpt.

I'm a big fan of datacamp. You should definitely give this a try. It would be great to expand the reach of your lessons without the infrastructure overhead of every user hitting your server with their code. Hit up the skulpt dev listserve if you want some help. Or I'm at elliott@trinket.io.

Plug: you could easily prototype this with Trinket embeds. Add #!/bin/python3 to the top of our Python (Skulpt) trinkets to get strict Py3 mode. Add data files via the + button (no directory support, so treat them as all in the local directory). Use the Share menu to get embed code. Paste. You've got your first interactive lesson. If your users like it, you can then decide whether and how to build skulpt in to the site.

Thanks for the pointers, I'll definitely have to take another look at trinket.io! It would be cool to try some exercise submission + feedback with code highlighting all on the client side.

I've always wondered, how do you isolate/protect against people doing nefarious things in a setup like that?

Virtual machine is probably the most common solution.

Yes, that kind of tool - that lets you run Python in a browser - can be useful. I had discovered, tried out and blogged about some of them earlier (also trinket.io, which you mention):

Codingbat, Progress Graphs and Michael Jordan:

(for Java and Python - when I tried it)

https://jugad2.blogspot.in/2013/02/codingbat-progress-graphs...

Online Python Tutor looks quite interesting:

(for Python)

https://jugad2.blogspot.in/2013/03/online-python-tutor-looks...

PythonMonk - learn Python in the browser:

(for Python)

https://jugad2.blogspot.in/2013/04/pythonmonk-learn-python-i...

glot.io, an open source pastebin with runnable snippets:

(for multiple languages)

https://jugad2.blogspot.in/2017/04/glotio-open-source-pasteb...

Some of them use emscripten, IIRC.

Edit: These tools are good for beginners to learn the basics of the language. For more complete learning, I still think the traditional method of using the command line tools such as the interpreter and a text editor, and an IDE, are useful and recommended. Interaction with the real OS is a part of the learning of any (at least industrial) programming language (maybe there are some specialized exceptions) - i.e. things such as files, databases, directories, users, processes, peripherals, etc. - and not much of that can be done in the browser-only environment that these tools have.

In fact, since I am a trainer too, I sometimes come across some of my students who do not know the basics of dealing with an operating system, even as a user. E.g. some of them can only use the PC via the GUI (e.g. in Windows) and are not familiar with the command line and its commands, or even with concepts such as drives, pathnames, filenames, absolute vs. relative paths, how to reference a file in dir B from dir A, etc. In such cases I always show them some of the basics of that stuff and give them references for further learning. And I tell them that if they do not learn that stuff (or look down on it, as a few of them tend to do), it is like knowing how to drive a car (programming) but not knowing how to walk from your house to the car and from the car to the shop - in other words, you are not fully capable to even use a car due to that :)

Hi there! One of the Skulpt maintainers here. (Also founder of Anvil - https://anvil.works. Never thought I'd have two projects on the front page at once!)

Feel free to ask any questions about the gory internals and how it works. You might also enjoy my talk from PyCon US this summer, about how Skulpt compiles blocking Python code into non-blocking Javascript: https://anvil.works/blog/pycon-talk

Thank you for building such a fantastic tool that has gotten so many more people coding in Python.

Thank-you! It's definitely a team effort, including several educators as well as the teams from Trinket and Anvil (where I'm a cofounder). A particular shout-out for Albert-Jan Nijburg, who does some contracting for Trinket but donates a lot of his own time to the project. (I think we're top two contributors at the moment, but this varies a lot - we also get summer students who are very helpful.)

I can second this sentiment. Meredydd and Albert Jan have made a good deal of Skulpt's most technically interesting features (which in turn enable a more seamless user experience). I'm a cofounder of Trinket and we knew early on that this project was something we would use heavily and wanted to support. We support more languages now (including server side Python, Java, and with R coming soon) but our skulpt-based free Python trinket remains our most popular one.

Our users have benefitted hugely from contributions by Meredydd, Albert Jan, Michael Ebert, Marie Chatfield, Scott Rixner, Brad Miller, and a whole bunch of other contributors. Go team!

Yesterday's discussion demonstrated quite a bit of interest in using Python everywhere:

Anvil: full stack web apps built only with Python | https://news.ycombinator.com/item?id=15584124 (Oct 2017, 195 comments) reply

It would be good if there was some compatibility between Skulpt and Brython an equivalent to Pip that worked on both would be great.

I'm a co-founder of Trinket and thought I'd explain why we chose Skulpt.

Client-side execution lets you do visual things that would be slow and complicated (maybe practically impossible) if you ran them server side. Visual results are one of the most important motivators for students learning to code.

Take our Sense HAT emulator, made in partnership with Raspberry Pi:

https://trinket.io/sense-hat

This uses 3D CSS and SVG to make a virtual Raspberry Pi that you can rotate around. The Sense HAT has a gyroscope, accelerometer, etc that kids can actually program to respond to these movements.

The alternative to this emulator was the Raspberry Pi Foundation sending boxes of computers to classrooms (which they still do). But the emulator makes this scalable while also synergizing with the computers: kids can download their code and run it on the real device if they want.

The next phase in the project is letting kids run their code in space. Mission Zero uses the emulator to let European kids get their code run on one of the Raspberry Pis in orbit on the International Space Station:

https://trinket.io/mission-zero

Skulpt makes this possible.

Why not Brython or RapydScript? Theoretically, either could do most of this. Skulpt is designed for the needs of teachers and learners. Those projects have slightly different goals (making Python a web scripting language and providing a Pythonic way to write JS, respectively) which may make them a better fit for your project but we've found Skulpt to meet our users' needs the best. Our users are teachers and students in middle and high school, and some undergrads, who want to write, run, and share programs and websites as quickly and easily as possible. They need reasonable speed, fidelity to Python and lots of fun visuals. Turtle, Matplotlib, and now the Sense HAT emulator provide the visuals.

Skulpt isn't perfect but it's got a great community and is getting better all the time. I think it's the clear best choice if your users are teaching or learning. And projects like Anvil (anvil.works) show how the project can work outside of education as well, in that case for non-specialist business analysts/ops people who would otherwise be stringing together spreadsheets.

creator of http://pythontutor.com/ here ... skulpt is great and i know one of its maintainers quite well. one use case that's important is using it to distribute self-contained zero-install tutorials onto computers such as school machines and those in less-well-resourced parts of the world without good Internet access. you can deliver an HTML/CSS/JS zip file on a USB stick or CD-ROM and get lessons up and running even without Internet access.

that said, though, one reason I haven't made the plunge to Skulpt and still choose to run Python server-side is that as students get more advanced, they will inevitably run into edge cases and other weird behavior where skulpt will not match CPython, and the error messages and other outputs they get will become inconsistent with expectations. that's why i still continue to run CPython server-side in a sandbox for http://pythontutor.com/

Urk! Albert-Jan is busily trying to wake someone up and get the site back up. Meanwhile:

Archive link: http://archive.is/leOnD

GitHub: https://github.com/skulpt/skulpt

Hacker News strikes again. I'm receiving a '503 Over Quota' from the site right now.

https://github.com/skulpt/skulpt while you wait

Or the Google cache http://webcache.googleusercontent.com/search?q=cache:6RzAnju...

Oh nooo, I'll try and track down the person that has the creds to fix this :) ...

How does this compare to Brython (http://brython.info/), apart from missing the Python 3 support? Are there any custom bindings to the browser API?

I think it's mostly a difference in approach. Brython sets out to "replace Javascript with Python" as the language of scripting the Web. This means it has custom bindings to the browser API, supports writing Brython in <script> tags, uses slightly funky/un-Pythonic operators to do DOM manipulation, etc. Brython code can't block, to my knowledge (although the Python 3 async stuff makes that constraint much less painful these days).

Skulpt is "a Python implementation in JS". It doesn't have built-in DOM bindings - it's typically used within a project like Anvil or Trinket which provides higher-level (and therefore more Pythonic) modules for display/input/IO. Skulpt code can block, which also helps keep those APIs simple.

I guess my summary would be that Brython is great for scripting your HTML in Python rather than Javascript, but Skulpt is best for providing a Python runtime in your app. Does that make sense? (Of course, you'd have to ask a Brython developer for their take on it ;) )

Why the quotes around "Python implementation in JS"? Isn't it literally just that?

They're quotes from each respective project's homepage :)

We are working on python3 support and skulpt does have a python3 mode which emulates the biggest differences between py2 and py3. (like from __future__ import).

But it doesn't understand any of the new syntax added by python3 yet.

Isn't the biggest difference between Python 2 and 3 and handling of Unicode? That's what motivated the break in compatibility in the first place.

But in Skulpt the strings don't quite work like any of the Python versions.

Python 2 has a combined str/bytes type and a separate Unicode string type:

  >>> type("hello") is type(u"你好")
  False
  >>> len(u"你好")
  2
  >>> len("你好")
  6

...whereas in Python 3 the str type is Unicode and the "bytes" type is a completely separate thing:

  >>> type("hello") is type(u"你好")
  True
  >>> len(u"你好")
  2
  >>> len("你好")
  2

Skulpt actually seems to work more like Python 3, except that 1) there is no way at all to work with bytes (that I can find), e.g. no encode/decode methods, and it 2) requires the "u" prefix if literals contain non-ASCII characters, even though the type of the resulting string is the same as without the prefix:

  >>> type("hello") is type(u"你好")
  True
  >>> len(u"你好")
  2
  >>> len("你好")
  SyntaxError: invalid string (possibly contains a unicode character) on line 1

Skulpt strings are javascript strings internally, wether or not you add u in front of a string doesn't actually change it's internal representation. We always strive to be as close to cpython as we can, but in this instance we chose to use javascript strings internally, very likely with the mentality that we would come back to this if and when it would be a requirement for one of us. :) Which it hasn't been I think.

Thanks for this succinct explanation! I've opened an issue on the skulpt repo. https://github.com/skulpt/skulpt/issues/731

Brython has a better design and mimic python in a more convincing way imo

Archive link if you get a 'Over Quota': https://web.archive.org/web/20171027212510/http://www.skulpt...

How long until we can compile Python to Web-assembly?

EDIT: I just realized this can mean two things:

1. Compiling python source code to Web-assembly.

2. Compiling the python interpreter/compiler to Web-assembly.

(Contributor to skulpt and pypy.js here)

That is a difficult question to ask and I think the original developer of pypy.js Ryan Kelly is most suited to answer it. There are some people that have tried feeding the asm.js from pypy.js to the asm.js -> wasm compiler.

Which with a lot of fiddling may work for the non-jitted version. But if you want all the pypy speed you'll want to jit wasm to the browser.

I would love to know if you can do synchronous calls in wasm.

As Albert-Jan and I discussed at PyCon this weekend, the long-term future for Skulpt quite possibly involves compiling to WASM rather than Javascript. This is very unlikely to happen until every modern browser supports WASM. Neither Trinket's educational mission nor Anvil's "web apps for the world" mission are compatible with leaving users behind just because their workplace or school runs IE.

The runtime can be remarkably small (Skulpt is 228kb minified and gzipped, including the standard library), so I think it's a feasible target. (Pypy.js is, of course, enormous!)

> This is very unlikely to happen until every modern browser supports WASM

WASM ships in every evergreen browser today: http://caniuse.com/#feat=wasm

Only significant browser missing it is IE; only Edge has support.

What @meredydd means is, leaving the compiler written in javascript but emitting wasm, so compiling python into wasm with javascript. Too many compilers! :P

The runtime is several Mo. Not worth it.

Could be worth it in many cases. Something more "app like" than "website like" where users would tolerate a longer initial startup time.

Apps are already slow enough as it is don't you think ?

Depends which ones you're talking about. I get the feeling we're talking at cross purposes.

Standard Python is nicer for writing clients in many cases.

We're back up! :)

The code won't run in my browser and I'm seeing Javascript errors. Hope this helps: https://i.imgur.com/gRLw9IW.png

Reply on news.ycombinator.com