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

[Guido van Rossum]

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)