[Python-Dev] PEP 484 update: allow @overload in regular module files

Guido van Rossum guido at python.org
Sat Mar 19 21:52:51 EDT 2016


Here's another proposal for a change to PEP 484.

In https://github.com/python/typing/issues/72 there's a long
discussion ending with a reasonable argument to allow @overload in
(non-stub) modules after all.

This proposal does *not* sneak in a syntax for multi-dispatch -- the
@overload versions are only for the benefit of type checkers while a
single non- at overload implementation must follow that handles all
cases. In fact, I expect that if we ever end up adding multi-dispatch
to the language or library, it will neither replace not compete with
@overload, but the two will most likely be orthogonal to each other,
with @overload aiming at a type checker and some other multi-dispatch
aiming at the interpreter. (The needs of the two cases are just too
different -- e.g. it's hard to imagine multi-dispatch in Python use
type variables.) More details in the issue (that's also where I'd like
to get feedback if possible).

I want to settle this before 3.5.2 goes out, because it requires a
change to typing.py in the stdlib. Fortunately the change will be
backward compatible (even though this isn't strictly required for a
provisional module). In the original typing module, any use of
@overload outside a stub is an error (it raises as soon as it's used).
In the new proposal, you can decorate a function with @overload, but
any attempt to call such a decorated function raises an error. This
should catch cases early where you forget to provide an
implementation.

(Reference for provisional modules: https://www.python.org/dev/peps/pep-0411/)

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list