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

2016-03-21 Thread Guido van Rossum
This seemed pretty uncontroversial. I've updated the PEP.

On Sat, Mar 19, 2016 at 6:52 PM, Guido van Rossum  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)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


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

2016-03-19 Thread Guido van Rossum
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)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com