Why not transpile python to JS instead of running an interpreter?
personally, i think pythons object model is extremely similar to js -- down to python essentially having prototypal inheritance
if you want to inherit from an object, just construct a class object from it using type().
Eg., at least, for any given object `me`,
type('ChildOfMe', (type(me),), vars(me))
type('ChildOfMe', (proxyclass(me),), {})
def proxyclass(obj):
class Proxy:
... dispatch to obj ...
return ProxyI suppose you could just say that classes are a particularly restricted sort of prototypes, and thus any class-based language is effectively prototype-based. But at that point "<OOP language> has prototype inheritance" is just tautological based on the set of definitions you've chosen.
Python is prototypal in just the same way js is: inheritance is a daisy-chain of references between objects.
JS is "maximally prototypal" if you like, where any object may be refernced. In python, only objects of type "type": but that isn't a big restriction, as shown.
- you can replace builtins in python. - you have __dunder__ methods and multiple inheritance. - JS has an ever running event loop and is async by default. - python is more strickly typed.
It's not impossible (see brython), but it's not easy either.
However, much appreciated.
It's perhaps interesting to note that browsers pretty much already implement this behaviour for js, ie., by spec everything is a float -- but vms don't start with a float type for much of the numeric data stored; and transparently move to it when needed.
Python descriptors are extremely flexible though, and I _guess_ you could emulate almost all of it through Javascript proxies, but I can't imagine the performance of that being great. Hash tables would also not be re-usable between JS and Python (since Python hash tables allow many more varieties of objects), and Python has a distinction between attributes and keyed access (which JS lacks).
Python exposes much more of the global environment and internals than JS does, and doesn't have some of the requirements JS has put on itself for security reasons. I'm not super sure you could emulate Python blocking style with a JS transformation statically. Blocking Python for something that is only available in a non-blocking JS environment would require effectively wrapping every Python operation (since almost every Python operation can have arbitrary side-effects).
I think there are people who write sort of syntax-y transpilers, but that's not really going to lead you down to nice code re-use.
https://github.com/adsharma/py2many/
Made a new release earlier today:
(I'm one of the maintainers)
edit: following some comments I want to add that the situation is symmetric IMO. I don't see the point in transpiling any of the two to the other.
You see more JS hate because it's a more common scenario that people happy with PHP/Python/Whatever would be exposed to JS later, than the other way around.
You see a bit more Python hate lately because ML is all the rage and Python is to ML what JS is to the web.
All mentioned languages having some weird backwards compatibility quirks doesn't help either.
I find it good that people are trying to port their favorite languages, although personally I'd stay on the happy path for the target platform. Especially the browser, as it already has weird APIs, JS or not.
Specifically, now that I'm very much OK with both python and JS I find transpiling one to the other kind of pointless in terms of any language property (can make sense in terms of ecosystem).
16 == [16]
>>> a = 5
>>> b = 5
>>> a is b
True
>>> a = -4
>>> b = -4
>>> a is b
True
>>> a = 300
>>> b = 300
>>> a is b
False
Most linters would display errors even if you did (in both languages).
The is operator checks to see if both point to the same area in memory. Small numbers are preallocated in python so they point to the same memory.
>>>a=300
>>>b=a
>>>a is b
True
The point was that both languages have pitfalls.
It is a pitfall. It's not about what python developers think about it. It is about what people from other languages experience when they learn the language.
(Though it's not my main point, I want to add as (also) a python developer, that I think this is a terrible design choice, which could easily be avoided. In this case python doesn't "threat everything as object" it treats small int literals differently than bigger int literals)
Regardless, if, as you said, the operational semantics of the language is inconsistent among implementations and depends on internal caching, it only makes it worse.
false