For example:
def foo(bar: int = None):
pass
When I check a type/annotation of bar
pycharm
No. Omitting Optional
was previously allowed, but has since been removed.
A past version of this PEP allowed type checkers to assume an optional type when the default value is None [...]
This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.
Some tools may still provide the old behaviour for legacy support. Even if that is the case, do not rely on it being supported in the future.
In specific, mypy still supports implicit Optional
by default, but explicitly notes this may change in the future:
Optional types and the None type (mypy v0.782)
[...] You can use the
--no-implicit-optional
command-line option to stop treating arguments with a None default value as having an implicit Optional[...] type. It’s possible that this will become the default behavior in the future.
The deprecation of this behaviour is tracked in mypy/#9091
A previous version of the standard, as defined in PEP 484 allowed for this.
However, the most up to date version states the following in the Union section:
A past version of this PEP allowed type checkers to assume an optional type when the default value is None, as in this code:
def handle_employee(e: Employee = None): ...
This would have been treated as equivalent to:
def handle_employee(e: Optional[Employee] = None) -> None: ...
This is no longer the recommended behavior. Type checkers should move towards requiring the optional type to be made explicit.
I'm glad about this. To my eyes, it actually looks jarring.