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.