Discussions-To PEP-0604: Explore extensions of isinstance() and issubclass()
Hello everybody, After the previous discussions, a new simplified version of PEP-0604 <https://www.python.org/dev/peps/pep-0604/> was published. I propose to add a similar syntax of Scala 3 <https://dotty.epfl.ch/docs/reference/new-types/union-types.html> 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. Your remarks are welcome. Philippe
I think it's a good idea to allow unions in isinstance() (and issubclass()). I recall occasionally getting questions about this from Dropbox engineers. The use case is usually having a list of types that is used both in isinstance() and in a type annotation, and trying to factor it so that if the list of acceptable types is changed, only one place has to be changed (following "DRY" principle). I've seen this often enough that I think it's a good idea, and PEP 604 will require having a builtin representation of unions anyway, so the implementation should be straightforward. On Thu, Oct 3, 2019 at 10:04 AM Philippe Prados <philippe.prados@gmail.com> wrote:
Hello everybody,
After the previous discussions, a new simplified version of PEP-0604 <https://www.python.org/dev/peps/pep-0604/> was published.
I propose to add a similar syntax of Scala 3 <https://dotty.epfl.ch/docs/reference/new-types/union-types.html> 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.
Your remarks are welcome.
Philippe _______________________________________________ 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/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
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 <https://www.python.org/dev/peps/pep-0604/> was published.
I propose to add a similar syntax of Scala 3 <https://dotty.epfl.ch/docs/reference/new-types/union-types.html> 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.
Your remarks are welcome.
Philippe _______________________________________________ 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/
On Fri, Oct 4, 2019 at 7:13 AM Jelle Zijlstra <jelle.zijlstra@gmail.com> 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
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 <rosuav@gmail.com> a écrit :
On Fri, Oct 4, 2019 at 7:13 AM Jelle Zijlstra <jelle.zijlstra@gmail.com> 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/
On Fri, Oct 4, 2019 at 4:54 PM Philippe Prados <philippe.prados@gmail.com> 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
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 <rosuav@gmail.com> a écrit :
On Fri, Oct 4, 2019 at 4:54 PM Philippe Prados <philippe.prados@gmail.com> 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
On Fri, Oct 4, 2019 at 7:53 PM Philippe Prados <philippe.prados@gmail.com> 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
Yes, it does. I will publish a new PR. Philippe Prados Le ven. 4 oct. 2019 à 12:00, Chris Angelico <rosuav@gmail.com> a écrit :
On Fri, Oct 4, 2019 at 7:53 PM Philippe Prados <philippe.prados@gmail.com> 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
participants (4)
-
Chris Angelico -
Guido van Rossum -
Jelle Zijlstra -
Philippe Prados