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

Guido van Rossum guido at python.org
Mon Mar 21 17:11:38 EDT 2016

This seemed pretty uncontroversial. I've updated the PEP.

On Sat, Mar 19, 2016 at 6:52 PM, Guido van Rossum <guido at python.org> wrote:

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)

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

More information about the Python-Dev mailing list