On Aug 29, 2019, at 18:10, Guido van Rossum <guido@python.org> wrote:
I think {int, str}, which someone proposed in one of the earlier discussions, is nice. What else would a set of types mean (unless you’re doing mathematical type theory rather than programming language typing)? But it’s unfortunate that things like isinstance and except take a tuple of types (and it has to be a tuple, not any other kind of iterable), so a set might be just as confusing for hardcore Python types as a tuple would be for polyglots.
If the compatibility issue isn’t a big deal (and I trust Guido that is isn’t), I think int | str is the best option. It’a an operator that means union, it’s used for sum/union types in other languages, it makes perfect sense if you read it as “int or str”… I cant imagine anyone being confused or put off by it.
I just realized one big advantage of `{int, str}` over `int|str`. It doesn't require adding anything to `type`,
Well, that was my initial worry with |, and I thought you did a good job arguing that it wasn’t a big deal… but I’m fine either way.
We could still do `~int` -- it would just return `{int, None}`. (But that *would* require adding to `type`.)
If we did this, it would behoove us to support `isinstance(x, {int, str})` as well.
What about other constructs that take a tuple of types? Should try/except take sets? (Are there any others?)
Would anyone be surprised that isinstance/issubclass take a tuple or set of types but all those string methods take only a tuple, not a set, of strings? I think people would get over that quickly, there’d just be another entry in the StackOverflow Python FAQ list.