In my current Proof of concept https://github.com/pprados/cpython/blob/update_isinstance/Objects/typeobject..., I use PyObject* typing=PyImport_ImportModule("typing"); and it's enough. At time, I am not an expert of all the source code. From my understanding, the buildin type must be enough to use Python, without other modules. It is just a pure CPU code. If I'm right, to add the operator __or__() and to update the isinstance() and issubclass(), I must have the _GenericAlias accessible without other modules. I can not import the module typing in isinstance() otherwise an infinite recursion arrives. I use a "bad trick" to resolve this problem. See here https://github.com/pprados/cpython/blob/update_isinstance/Objects/typeobject... and here https://github.com/pprados/cpython/blob/update_isinstance/Objects/abstract.c... . The code must be better if I can have direct access to _GenericAlias type. So, I imagine this class must be in buildin, or indirectly accessible by buildin methods and functions, without the import of typing. What do you think? Philippe Le jeu. 3 oct. 2019 à 23:17, Chris Angelico a écrit :

On Fri, Oct 4, 2019 at 7:13 AM Jelle Zijlstra wrote:

...

El jue., 3 oct. 2019 a las 10:04, Philippe Prados (<

philippe.prados@gmail.com>) escribió:

...

...

Hello everybody,

After the previous discussions, a new simplified version of PEP-0604

was published.

...

I propose to add a similar syntax of Scala 3 in Python, to accept an or

operator.

...

# Operator for Union assert( int | str == Union[int,str])

The isinstance() and issubclass() were extended to accept this new

syntax:

...

isinstance(int, int | str) It's not really explored. To accept this evolution, the object Union (and dependencies) now be

available as a builtin.

...

By "available as a builtin", do you mean that it will be in the builtins module, so that the `Union` name will always be accessible anywhere, or simply that the `Union` object will be built into the Python interpreter? Only the latter is actually technically necessary as far as I can see. For example, functions are instances of `types.FunctionType`, which is a "builtin" object, but not actually in the `builtins` module.

There are some changes pending on the PEP text and I believe this will be one of the topics discussed. Philippe, can you assess the PR and the comments, and clarify the parts of the proposal regarding this object and where it'll live?

ChrisA _______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/

For the specification, I propose just to update isinstance() and issubclass(). And, for the implementation, I propose to migrate the _GenericAlias in core, that doesn't have a directly-accessible name or via alias in typing module. We will analyse the implementation later. Ok ? I can update the "Technical Point of Vue https://github.com/pprados/peps/blob/pep-0604/pep-0604.rst#technical-point-o..." to mention this, before the next PR. Philippe Le ven. 4 oct. 2019 à 10:16, Chris Angelico a écrit :

On Fri, Oct 4, 2019 at 4:54 PM Philippe Prados wrote:

...

In my current Proof of concept, I use PyObject*

typing=PyImport_ImportModule("typing");

...

and it's enough. At time, I am not an expert of all the source code.

From my understanding, the buildin type must be enough to use Python, without other modules.

Correct.

...

It is just a pure CPU code. If I'm right, to add the operator __or__() and to update the isinstance() and issubclass(), I must have the _GenericAlias accessible without other modules. I can not import the module typing in isinstance() otherwise an infinite recursion arrives. I use a "bad trick" to resolve this problem.

You're writing a language proposal. You can suggest whatever makes the most sense, such as creating a new builtin name, or creating a new core object that doesn't have a directly-accessible name, or whatever it takes. Just be specific as to what you _are_ proposing.

We can discuss further on the PR's comments if that's easier.

ChrisA

Yes, it does. I will publish a new PR. Philippe Prados Le ven. 4 oct. 2019 à 12:00, Chris Angelico a écrit :

On Fri, Oct 4, 2019 at 7:53 PM Philippe Prados wrote:

...

For the specification, I propose just to update isinstance() and

issubclass().

...

And, for the implementation, I propose to migrate the _GenericAlias in

core, that doesn't have a directly-accessible name or via alias in typing module.

...

Cool. Does the PEP say this now?

ChrisA