On Thu, Sep 5, 2019 at 7:08 PM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote:
On Sep 4, 2019, at 20:51, Inada Naoki <songofacandy@gmail.com> wrote:
And you’re right, because int|str _looks_ better than (int, str) here, many people will be encouraged to use it even though it’s slower, which could potentially be a bad thing for some programs.
That's exactly my point. If we say "you can use `isinstance(x, int | str)` for now", people may think it is a new and recommended way to write it.
Right; I was agreeing, and saying it may even be worse than you’re suggesting. There’s always the possibility that any shiny new feature looks like the One True Way and gets overused. But in this case, it looks more obviously right even to someone who’s not interested in shiny new features and has never heard the word “pythonic” or read a new version’s release notes. So they’re going to use it. Which means if they run into a situation where they’re checking types of a zillion objects, they’re definitely not going to guess that it’s 5x as slow, so there definitely going to misuse it.
Hang on hang on.... what's this situation where you're checking types of a zillion objects? I think there's a bigger problem there than whether isinstance(x, int|str) is slower than isinstance(x, (int,str)) ! Even if this change DOES have a measurable impact on the time to do those checks, it only applies to unions, and if that's a notable proportion of your total run time, maybe there's a better way to architect this. The only situation I can think of would be exception handling. As a special case, BaseException could perhaps have an __or__ method that returns a tuple, but even there, I'd want to see a macrobenchmark that shows that the difference actually affects a larger program (especially since most exception checks are by hierarchy, not by union). ChrisA