On Thu, Sep 05, 2019 at 12:12:05PM -0700, Andrew Barnert wrote: > On Sep 5, 2019, at 04:24, Steven D'Aprano <st...@pearwood.info> wrote: > > > > But having said all that, I'm not sure that we should be rejecting this > > proposal on the basis of performance when we haven't got any working > > code to measure performance of :) > > Good point. But then if we never get any realistic use cases, it’ll > probably already be rejected for that reason. :)
Sorry, I don't understand your point about realistic use-cases. The realistic use-case for int|str (or Union[int, str]) in isinstance is exactly the same as the use-case for (int, str) and we've had that for many, many releases. I didn't think we still have to prove the utility of checking whether an object was an instance of class A or B. This is about making the syntax look pretty, not adding new functionality. There are two proposals here: * allow str|int in type annotations, as a nicer-looking and shorter equivalent for Union[str, int] * allow Unions (whether spelled explicitly or with the | operator) to have runtime effects, specifically in isinstance and I presume issubclass, as a nicer-looking alternative to a tuple of classes. (The first is a necessary but not sufficient condition for the second.) Both are cosmetic changes. Neither involves new functionality which doesn't already exist. I don't think use-cases come into it. This seems to me to be a pair of purely design questions: * are Unions important enough to get an operator? (I think so.) * is it reasonable to relax the prohibition on isinstance(obj, Union)? (I think so.) although there are subtleties that need to be considered, as your post goes on to mention. -- Steven _______________________________________________ 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/74PMWNRZLW2BJ2M6AXLKF5NMUPFF5CR2/ Code of Conduct: http://python.org/psf/codeofconduct/
