Let's not do `except E1|E2`. It doesn't look like a readability improvement over `except (E1, E2)`, and I don't think there's much of a use case for having a type alias such as `E = E1|E2` that's both used in annotations and in an except clause. (If you show me real code that contradicts me I might change my mind.)

Even though exceptions are classes, their use and handling is almost completely separate from the types we use for type checking. (In contrast with isinstance(), which does play a legitimate role in type refinements.)

--Guido

On Wed, Sep 25, 2019 at 1:25 AM Philippe Prados <philippe.prados@gmail.com> wrote:

Ok. I agree.

I will split the PEP. The next version I'm going to submit propose only int | str, int | None, and isinstance(x str | int).
What do you think about that ?
except int | str :

Philippe Prados

Le mar. 24 sept. 2019 à 22:42, Ivan Levkivskyi <levkivskyi@gmail.com> a écrit :
On Tue, 24 Sep 2019 at 13:13, Guido van Rossum <guido@python.org> wrote:
Since you mentioned my name, let me explain my current position on how to spell "optional".

- We've had a lot of feedback from mypy users who were confused by Optional[T] and thought this was needed for "optional" function arguments (i.e. those that have a default).

- Another situation where people have been confused Optional is in TypedDict, where we wanted to have a way to say "this key may be present or absent" (in the end we couldn't find a good keyword for this so we went with "total=<bool>" for the entire dict).

- It would probably have been less confusing if it had been called "nullable" (or "noneable"? Ruby's Sorbet type system calls it "nilable").

- In TypeScript you just write "int | None", and that looks readable enough to me -- and perfectly unambiguous.

So my preference would be to drop the "~" proposal (or aspirations for "?") and instead just write "int | None".

IIRC at last Friday's Bay Area typing meetup there was general agreement with this sentiment.

Yes, most people agreed that `~` is not a good idea, and we should just go ahead with `int | None`. Also most people agreed we may reconsider `int?` in a separate PEP later (possibly in conjunction with PEP 505).
Btw, majority of people also agreed that allowing `isinstance(x, int | str)` is a good idea (mostly for type aliases that can be used both at runtime and in an annotation) assuming `isinstance(x, str | List[str])` is still an error.

If the PEP authors don't have problems with this, then I would propose to move towards discussing details of the proposed implementation.

--
Ivan