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>