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

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

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

(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