
On Thu, Sep 05, 2019 at 12:12:05PM -0700, Andrew Barnert wrote:
On Sep 5, 2019, at 04:24, Steven D'Aprano <steve@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