Guessing `new` intent might lead to undesired errors. about pyodide HOT 4 OPEN

More generally this is a problem with all attributes defined on JsProxy. The logic we have for JsProxy __getattribute__ is here:
https://github.com/pyodide/pyodide/blob/main/src/core/jsproxy.c#L321-L324
It always gives the C definitions preference over methods on the JavaScript object. Perhaps we could come up with something a bit more sophisticated, or special case "new", or something else.

Interestingly in __setattribute__ we almost always assign through to the JavaScript object:
https://github.com/pyodide/pyodide/blob/main/src/core/jsproxy.c#L374-L397
so that we get the following odd behavior:

from js import Object
Object.new = 6 # assigns to Js Object
print(repr(Object.new)) # <built-in method new of pyodide.ffi.JsProxy>
assert run_js("Object.new") == 6

from pyodide.

For some reason this code has gotten a lot less attention than the corresponding code on PyProxy.

from pyodide.

To whom it might concern, this is how Function.prototype.new proposal (or polyfill, if used) would enhance / improve by far the situation (imho) https://es.discourse.group/t/function-prototype-new/1772/40

Here I think there could be issues with 3rd party libraries as one can't assume anything, not even common sense, out there 😅

from pyodide.

I've proposed an alternative that this project might as well use: https://github.com/WebReflection/proxy-class-new#readme

It doesn't land on Function.prototype and it addresses most known/explored edge cases ... feel free to use it internally to disambiguate classes and instantiate these with .new(....args).

from pyodide.