Thanks Andrew for spending so much time answering me. I publish a new version <https://github.com/pprados/peps/blob/master/pep-9999.rst> of the proposition with a synthesis of remarks, and a separation between strong and optional proposition.
* You need __ror__ as well as __or__. No, in this situation, Python auto invoke ``__or__`` in case of ``__ror__``. * The static types in typing are not instances of type, so you need to work out what to do with them. I do not understand the remark. My patch of 'mypy' accept this new syntax. * Making isinstance work isn’t a matter of accepting new syntax as you suggest, but making the values already created by the existing syntax work—and, since this appear to have been deliberated removed in 3.6, you need to explain why this was a mistake and should be undone. (Have you uncovered the reason for this change?) And whether it should affect just Union or other types. Where I can find the argument to explain why this have been deliberated removed in 3.6 ? In my implementation, they affect just Union. isinstance() can now accept type, Tuple or Union. * What about except clauses? Shouldn’t they take unions if isinstance does? How does that work? Good question. To accept `except TypeError | ZeroDivisionError:` in place of `except (TypeError, ZeroDivisionError):`, the impact is bigger, but why not ? * You also need unions to work on the first argument of issubclass for one of your previous examples, which is different from the rules on the second argument of isinstance and issubclass, and was also apparently deliberately removed in 3.6. Is that still part of the proposal? Why, or why not? I find a link <https://github.com/python/typing/issues/387> who explain "it's to late". Do you have another link ? * Should you be able to test whether List or List[int] is a subclass if List|Tuple or List[int]|Tuple[int]? If so, that reverses even more of the 3.6 change, and then you have to explain why you can’t use issubclass(List[int], Iterable[int]) or issubclass(List[Integral], List[int]) but can use this. If not, what’s the use case for issubclass with unions in the first place? It's a question for "typing". My proposition change nothing about that. * You will probably want to create a new builtin type for unions, rather than having a bunch of different parts of the Python core import from typing. May be. * In addition to other benefits, someone (Stephen?) pointed out that builtin support could mean that, e.g., isinstance(3, int|str) could be just as efficient as isinstance(3, (int,str)), which alleviated multiple people’s concerns. Is that’s part of the proposal you should make that point; if not, explain why not. The implementation use the tuple present in the Union type. The impact is just to check the type of the second parameter and replace it with the tuple from the Union. * The match with the normal meaning of the | operator is a strong argument for your proposal, so it’s probably worth mentioning. (Whether you read it as union or as or, it does what you expect.) But you also need to address ~ being potentially confusing. (Whether you read it as not or complement or invert, it doesn’t do anything near what you expect, but there are only so many operators and Optional is so useful that it’s worth getting used to this. At least you quickly sold Guido with that argument, so I think it would work just as well in the PEP, if it’s there.) Yes * There’s usually a section on rejected alternatives, where you can explain why just making static type tools handle a tuple or set or frozenset of types isn’t better than making isinstance work with unions and creating them with |. I extend this section with all arguments for now. * Mentioning the wide variety of other languages’ typing systems that use | for related features would probably make it more compelling. I find only Scala now. Philippe Le mar. 17 sept. 2019 à 18:51, Andrew Barnert <abarn...@yahoo.com> a écrit : > On Sep 17, 2019, at 08:03, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > > > > Note that there is a related PEP 585, and the outcome for this one may > depend on that PEP. > > It seems like Phillipe could write two versions. > > If PEP 585 is accepted, then type.__or__ should not exist, and int|str > should only work in annotations, taking advantage of annotations no longer > being completely evaluated at runtime, just like list[int]. And that means > no using it with isinstance, no builtin, etc., of course. Which makes for a > very different proposal. > > If PEP 585 is rejected, then this proposal as-is becomes more compelling, > and might even point toward further static/runtime integrations that could > be done without major costs. > > In fact, having the two versions both ready could help clarify the > discussion about PEP 585, and more generally about the advantages and > disadvantages of going more toward a “two-kinded” type system vs. leaning > more into “everything is first-class”. >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VDSF53HQN6ZNOA2VQRMO4AH5VWAW4LQJ/ Code of Conduct: http://python.org/psf/codeofconduct/
