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
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
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