Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Skulpt: client side Python without preprocessing

skulpt.org

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Skulpt: client side Python without preprocessing

#21

Post by ptx »

albertjan wrote: post #12
eigengrau wrote: post #3

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?

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

Re: Skulpt: client side Python without preprocessing

#22

Post by albertjan »

ptx wrote: post #21
albertjan wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Skulpt: client side Python without preprocessing

#23

Post by albertjan »

ptx wrote: post #21
albertjan wrote: post #12

Earlier quoted context omitted.

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…

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

Re: Skulpt: client side Python without preprocessing

#24

Post by eah13 »

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.

Re: Skulpt: client side Python without preprocessing

#26

Post by eah13 »

sametmax wrote: post #14
primitivesuave wrote: post #5

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 pyga…

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.

Re: Skulpt: client side Python without preprocessing

#30

Post by meredydd »

albertjan wrote: post #11
amelius wrote: post #10

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 t…

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!)

Post reply on HN