Can I omit Optional if I set default to None?

Question

For example:

def foo(bar: int = None):
    pass

When I check a type/annotation of bar pycharm tells me that it is Optional[int].

bar: int = None looks much cleaner rather then bar: Optional[int] = None, especially when you have 10+ parameters.

So can I simply omit Optional? Will tools like mypy or other linters highlight this case as en error?

Looks like python itself doesn't like the idea:

In [1]: from typing import Optional
In [2]: from inspect import signature

In [3]: def foo(a: int = None): pass
In [4]: def bar(a: Optional[int] = None): pass

In [5]: signature(foo).parameters['a'].annotation
Out[5]: int

In [6]: signature(bar).parameters['a'].annotation
Out[6]: typing.Union[int, NoneType]

Answer 1

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

Answer 2

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.