On Aug 29, 2019, at 18:10, Guido van Rossum <[email protected]> wrote:
>
>> On Thu, Aug 29, 2019 at 5:56 PM Andrew Barnert via Python-ideas
>> <[email protected]> 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._______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/5KOVTOSKE7BLQNGADTRITMXK54R3AOYZ/
Code of Conduct: http://python.org/psf/codeofconduct/