On Sep 16, 2019, at 23:54, Philippe Prados <philippe.pra...@gmail.com> wrote: > > Hello, > > I would like to publish a new PEP (see here). > I discussed this idea here.
Your PEP is missing any mention of some key issues that came up during the discussion, and I suspect you want to make it more complete before getting a sponsor. Some issues, like figuring out what if anything needs to be benchmarked, maybe you can wait until you have a sponsor who can help you work them out. But things where you know exactly what needs to be done, you’re probably better off doing that now. I don’t know how PEP sponsorship works, but I suspect something that’s 90% of the way to ready for final discussion will attract a sponsor more easily than something that’s only halfway there. * You need __ror__ as well as __or__. * The static types in typing are not instances of type, so you need to work out what to do with them. * 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. * What about except clauses? Shouldn’t they take unions if isinstance does? How does that work? * 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? * 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? * 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. * 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 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.) * 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 |. * Mentioning the wide variety of other languages’ typing systems that use | for related features would probably make it more compelling.
_______________________________________________ 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/FCQIMAWBBVF2S7U3PYJ67HVXCZKLOAAL/ Code of Conduct: http://python.org/psf/codeofconduct/
