Live data from Hacker News

Brython: an implementation of Python 3 running in the browser

github.com

51–60 of 76 posts

Re: Brython: an implementation of Python 3 running in the browser

#51

Can I hijack this post for a nit-pick? While I love Python and feel most comfortable with it, it always bothered me that it make a distinction between accessing a dictionary item and accessing an object member. E.g.: a["getStuff"]() # call the "getStuff" function of dictionary "a" b.getStuff() # call the "getStuff" method of object "b" In contrast, in JavaScript, these two are equivalant. a["getStuff"]() a.getStuff()…

Highly recommend looking into Munch, "a dictionary that supports attribute-style access, a la JavaScript." https://github.com/Infinidat/munch

In theory, implementing attribute-style access on user-defined Python object is just a matter of overriding its __(get|set)attr__ methods, for example:

    In [1]: import collections
    In [2]: class DotDict(collections.UserDict):
          2     def __getattr__(self, k):
          3         try:
          4             return self.__getitem__(k)
          5         except:
          6             return super().__getattribute__(k)
          7     def __setattr__(self, k, v):
          8         try:
          9             self.__setitem__(k, v)
         10         except Exception as e:
         11             super().__setattr__(k,v)
    In [3]: d = DotDict({'a': 'b', 'c': [1,2,3], 'square': lambda x: x*x})
    In [4]: d.square(4)
    Out[4]: 16
    In [5]: d
    Out[5]: {'a': 'b', 'c': [1, 2, 3], 'square':  at 0x7f9ef5d5b0d0>}
    In [6]: import datetime
    In [7]: d.created_at = datetime.datetime.now()
    In [8]: d
    Out[8]: {'a': 'b', 'c': [1, 2, 3], 'square':  at 0x7f9ef5d5b0d0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}

In practice, this can lead to headaches. Take, for example, what happens if we try to serialize `d` (which has a non-serializable lambda function in its keys) using the built-in pickle module:

    In [9]: import pickle
    In [10]: pickle.dumps(d)
    Traceback (most recent call last):
      File "", line 1, in 
    _pickle.PicklingError: Can't pickle : attribute lookup DotDict on builtins failed
Thankfully there's a third-party library called cloudpickle which can serialize just about any python object to bytes -- even including the user-defined DotDict class (!):

    In [12]: deserialized_d = cloudpickle.loads(cloudpickle.dumps(d))
    In [13]: deserialized_d
    Out[13]: {'a': 'b', 'c': [1, 2, 3], 'square':  at 0x7f9ef650fee0>, 'created_at': datetime.datetime(2021, 7, 19, 19, 42, 32, 341393)}
Since the entire class definition is serialized along with the instance, the deserialized copy preserves the object's attribute-style interface as before:

    In [14]: deserialized_d.created_at.strftime("%c")
    Out[14]: 'Mon Jul 19 19:42:32 2021'
But I recommend Munch over rolling your own because subclassing `dict` is fraught with a surprising number of edge cases.

Re: Brython: an implementation of Python 3 running in the browser

#52
post #36

Earlier quoted context omitted.

The "y to CSS" part would still be there - even with WebAssembly, your UI options are still pretty much the DOM (great for documents and form entry, not so great for applications) or canvas (too low level and loses platform consistency, accessibility, usability, really every affordance of an operating system).

I'm going to ask an ignorant question and I'm sorry, but couldn't you basically write an application in web assembly, using OpenGL and creating whatever UI you wanted in there, and just use CSS for the scaffold? You'd only need a mobile and desktop web app, but you'd need one anyway, right? (Note.. I'm very obviously not a web developer, so forgive my naivete).

Yes. For example: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...

But it's going to be a very "heavy" custom framework that takes time to download and load. Overkill in most cases.

Re: Brython: an implementation of Python 3 running in the browser

#53
post #41

Earlier quoted context omitted.

Technologies like TypeScript are still dependencies that require transpiling to vanilla JavaScript and add to the bundle size. While typescript is becoming more and more common (for good reason) it still is effectively a workaround that compensates for the unergonomic-ness of the browser environment. You could make the same argument for frameworks like Angular, React and Vue. If WebAssembly replaced js, then newer, m…

If TS is eventually added to the JS standard, I would be very happy. I've only picked it up in the past few weeks, but I'm consistently amazed at how much sense it makes

You can actually annotate typescript types using JSDoc comments. So if you don’t like the added step of compiling your source down to JavaScript you can still write JavaScript with doc comments and then typecheck with `tsc --noEmit` which won’t run the compile step.

However I do see the appeal of the ergonomic of the TypeScript syntax. I hope TC39 will add something like optional type annotations to the spec.

Re: Brython: an implementation of Python 3 running in the browser

#54

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.

Re: Brython: an implementation of Python 3 running in the browser

#55

This project will transpile python code to JavaScript code instead of something WASM-based, like pyodide [0]. What are there the performance and usability consequences of each approach (py to js vs. py to wasm)? [0] https://github.com/pyodide/pyodide

(Disclosure: I'm a maintainer of https://skulpt.org , another Python-in-the-browser runtime, as well as a Python web framework/dev environment that uses it, https://anvil.works ) The short answer is that basically all the current Python-in-the-browser implementations (and there are a few!) predate widespread support of WASM. But even once WASM is a thing, you get a choice between: 1. Compile a full Python environment…

It would be cool to compile a Python program (not runtime) to WASM. Nuitka compiles Python to a native program, but I think it still deals with a lot of runtime overhead, and I don't think an equivalent for WASM is coming soon.

Re: Brython: an implementation of Python 3 running in the browser

#56

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser env…

Not having direct access to the file system or the network or to a database are because of the sandbox, not because of JavaScript. You can do all those things in Node.

Web Assembly isn’t going to get rid of the sandbox.

Re: Brython: an implementation of Python 3 running in the browser

#57

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

I’ve noticed both “plain HTML please” and “Wasm is awesome” sentiments expressed on HN. I wonder if these reflect two distinct subpopulations, or if there is an intersection of HNers who like both ideas.

The existence of both sentiments speaks to the idiosyncratic history of the web. The browser is powerful because it has grown to be ubiquitous, but also has this odd dual mandate of displaying static content and running dynamic apps.

Re: Brython: an implementation of Python 3 running in the browser

#58
post #48

Earlier quoted context omitted.

This is something that I wanted to hear more from people invested in frontend. I work exclusively as a DevOps/DataOps/Backend engineer and have little contact with stuff running in the browser. I did, however, work with AngularJS back in the day, and although the framework itself didn't lend itself to nicely to productivity and simplicity, I believe that what I found most confusing was how unergonomic the browser env…

The problem was WebAssembly despite what people think isn't a JS replacement. WebAssembly isn't designed to go after DOM manipulation and the rest of the browser world (in short, think calculating physics and heavy number crunching instead of whether or not some input with id blah is blank). The best analogy I can give is this, imagine using Lua and calling of compiled code (C/C++/Rust/etc), this is the JS/WebAssembl…

What would you change?

Re: Brython: an implementation of Python 3 running in the browser

#59

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

I don't think Webassembly will ever replace Javascript in the browser. Javascript has a low barrier of entry and if you are creating React/Angular sites there's little to gain from Webassembly for someone not interested in safer languages.

Saying that I am really interested in Webassembly and think the word web in Webassembly does it a disservice.

I have started to think of Webassembly as a light weight JVM. It's heavy sandboxing makes it really interesting as an evolution to FaaS (Function as a service) such as AWS Lambda. Lucet which Fastly is using for their Compute@Edge reports 35 micro second code start time! I can't wait until Fasly put there Compute@Edge on general release so I can try it. I've been playing with Cloudflare workers and as they us Chrome to run WASM files you have to mess about writing Javascript shims so a bit rough around the edges debugging.

Webassembly should realise the original goals of serverless providing a cross platform runtime with security guarantees and be fast and lightweight.

Most people package an entire OS in Docker containers, with WASM they get a small cross platform artifact. This project already looks like a way to run them in K8s https://github.com/deislabs/krustlet.

It also looks great for cross platform media devices. Have the bulk of your code as a WASM binary and then have very thin platform specific shim the WASM interacts with.

Re: Brython: an implementation of Python 3 running in the browser

#60
post #54

I'm hoping web assembly eventually completely replaces javascript. It would be amazing if we could theoretically compile any language down to be browser compatible.

idk how I feel about web assembly. At least now we can see what client-side javascript is doing. If WASM becomes mainstream then all client side code is going to be essentially binary blobs.

With all the minification and JS being used as a compile target for other languages it's already essentially binary blobs.
Post reply on HN