PEP 484 update: allow @overload in regular module files
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-@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)
This seemed pretty uncontroversial. I've updated the PEP. On Sat, Mar 19, 2016 at 6:52 PM, Guido van Rossum <guido@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-@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)
participants (1)
-
Guido van Rossum