I propose to use a unary operator to help the readability. With a lot of parameters:

def f(source: str | None, destination: str | None, param: int | None):...

I think it's more readable with

def f(source: str?, destination: str?, param: int?): ...

I propose two branches in my implementation: add_OR_to_types (for Union syntax) or add_INVERT_to_types (for Union and Optional syntax).

For me, the best proposition is to use str? like kotlin (with new unary operator ?).



Le jeu. 29 août 2019 à 17:00, Philippe Prados <philippe.prados@gmail.com> a écrit :

With PEP 563, there's no runtime behaviors.

It's strange to accept :

def f() -> int | str: ...

but not

a = int | str

The operator type.__or__() is called only if the user known what they do. it's strictly equivalent to

a = Union[int,str]

So, I think it's important to add this operator in root type.



Le jeu. 29 août 2019 à 14:55, Inada Naoki <songofacandy@gmail.com> a écrit :
I don't want to add runtime behaviors for static type hinting.

There is PEP 563 instead.
Tools like mypy can implement them without touching runtime behavior.


--
Inada Naoki  <songofacandy@gmail.com>