Python's object semantics are extremely different from JS. There might be _some_ ways of emulating them with JS thanks to Proxy objects nowadays, but you're looking at a pretty big uphill battle I think.

are you sure? can you give an example?

personally, i think pythons object model is extremely similar to js -- down to python essentially having prototypal inheritance

That's an interesting way to put it. Python does have a form of prototypical inheritance (given how objects end up being `__dict__`s with behaviour defined through `__class__`, though not only that!).

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.

Numbers. Everything is a float in JS. Python has ints that transparently turn into bigints on demand, floats, and if you need it a whole library of C numeric types to do interop (along with complex numbers and all kinds of other great stuff in python's standard library).

My point was more about the object model itself being incredibly similar, rather than the data types.

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.

The entire VM is different:

- 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.

I don't think you have that quite right. Objects don't inherit from other objects in Python — you can't do `class Foo(object())`, for example. Python has class-based inheritance.

classes are objects, and inheritance is just the __mro__ on a class -- ie., its prototypal chain

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

But if you wanted a more literal dispatch to `me` you could create a proxy class which dispatched to a reference to `me`.

    type('ChildOfMe', (proxyclass(me),), {})

Where `proxyclass` is a function of the form,

    def proxyclass(obj):
        class Proxy:
            ... dispatch to obj ...


        return Proxy

"If you want to inherit from an object, just create a class based on that object" is a description of how you'd imitate prototype inheritance in a language that only has class-based inheritance. It does not mean you're actually looking at a prototype-based language, and in fact strongly suggests the opposite. You can't get inheritance in Python without engaging with the class system.

I 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.

It's not tautological. I don't think C#, C++, Java, etc. can have classes proxy for objects. Classes there aren't objects. You cannot write "return NewClass".

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.

Different Python programs use different subsets, so as you work towards supporting more programs the union of the subsets becomes essentially the full set, I would assume.

The distribution of popularity of the features is not uniform. My intention is to carefully look at the intersection of relatively less used features and features that make python slow/inefficient and exclude them from the supported subset.

That's https://github.com/QQuick/Transcrypt

I'm looking into a python -> dart -> js approach. Emphasis on static type checking and small feature set that's easy to understand.

https://github.com/adsharma/py2many/

Made a new release earlier today:

https://adsharma.github.io/py2many0.2.1/

Because a large part the Python ecosystem uses packages (and stdlib modules) with C extensions and you can't easily transpile those. The end goal of Pyodide is to be able run existing projects mostly without modification in the browser, and that is not possible if one doesn't support Python C extensions.

(I'm one of the maintainers)

The parent is talking about transpiling python to JS. I don't see why people who hate JS would like python. The language itself is not any better IMO (excluding ecosystem here).

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.

Aggressive type coercions in js frequently comes up

  16 == [16]

true in js false in python

    >>> a = 5
    >>> b = 5
    >>> a is b
    True
    
    >>> a = -4
    >>> b = -4
    >>> a is b  
    True
    
    >>> a = 300
    >>> b = 300
    >>> a is b
    False

Every language has these, JS a bit more (because mostly impossible to fix thanks to backward compatibility). I don't understand why you would do that anyway.

Most linters would display errors even if you did (in both languages).

a==b would be true. The is operator is not the same as the equality operator

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

Of course there is some internal logic.

The point was that both languages have pitfalls.

In python it completely makes sense because it's an object oriented language and threat everything as object. In fact it's very consistent about that. Even classes are object and instance of metaclass. Difference between '==' and 'is' is came from that. This is not the case with Javascript. It's sad many peoples who are dealing with python don't understand that.

"-In python- it completely makes"

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)

Small integeres are object in python. They are cached in some implemention. If you only care about shallow syntax, yes it's confusing. But if you care more about semantics, it's completely consistent and doesn't make especial case.

Many programmers do care about the "shallow" syntax.

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.

jsc >> 16 === [16]

false

Great. Thank you. I'll remove the "is" operator from the supported subset and perhaps rewrite the commonly used "a is None" to idiomatic code in the target language.

You should always use 'is' with None. == Is operator that can be overloaded and 'is' is object identity comparison. It make sense when you understand object system. You will be terribly messed up when use some numpy array == None.

I really wish it didn't though. I started working with js ~5 years ago and haven't used == a single time, there are eslint rules that error on it[0] and you can reject push to repo if you have them, which many companies do. It's not a problem.

[0] https://eslint.org/docs/rules/eqeqeq

It's just what you are used to. I dislike Python, I hate PHP, but I really like JS. I've seen people like PHP and hate Python too.

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.

I agree, I was fluent in JS and other languages before learning python and hated it for a while. Eventually, you get used to the bad parts of any language so they become mostly transparent (and every language has bad parts).

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

Python is loads better than JS. I have experience with both.

Is dart your preferred alternative?