[Python-Dev] PEP 484 -- proposal to allow @overload in non-stub files

[Guido van Rossum]

On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 22 October 2015 at 19:51, Guido van Rossum <guido at python.org> wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <greg at krypto.org>
> wrote:
> >> What would it Foo.__getitem__.__annotations__ contain in this situation?
> >> It'd unfortunately be an empty dict if implemented in the most trivial
> >> fashion rather than a dict containing your Unions... Do we care?
> >
> > Initially it would indeed be {}. Once we have a true multi-dispatch PEP
> we
> > can iterate, both on how to spell it (perhaps the final __getitem__
> needs an
> > @overload as well) and on what happens in the annotations (or at least,
> what
> > typing.get_type_hints() returns).
>
> Just ensuring I understand the problem with using a third @overload in
> the spelling from the start:
>
>     class Foo(Generic[T]):
>         @overload
>         def __getitem__(self, i: int) -> T: ...
>
>         @overload
>         def __getitem__(self, s: slice) -> Foo[T]: ...
>
>         @overload
>         def __getitem__(self, x):
>             <actual implementation goes here>
>
> If we did this, the implied annotation on the last method would be:
>
>     @overload
>     def __getitem__(self, x: Any) -> Any:
>         <actual implementation goes here>
>
> which gets the signature wrong - this isn't an Any:Any mapping, it's a
> sequence.
>

Well, a type checker could handle the special case of the last overload.
There should be a rule that overloads are handled in the order in which
they are processed; it's not explicit in the PEP but it's meant to be that
way, in case there's overlap between signatures. (This differs from
singledispatch: when overloading on multiple types it's not always possible
to disambiguate by using the most derived type.)

But allowing this in code without having a full-fledged multi-dispatch
implementation in @overload would cause confusion in readers, which is why
we decided to disallow it outside stubs.


> Leaving the "@overload" out thus indicates that the definition is an
> implementation of the preceding type based dispatch declaration,
> rather than a new overload.
>

Yeah, that was the proposal. But I no longer think it's worth it.


> Assuming a future multidispatch implementation used
> "functools.multidispatch" as the decorator (to complement the existing
> functools.singledispatch) rather than "typing.overload", this seems
> like a reasonable short term solution to me.
>

But once we have a functools.multidispatch, why would we also need
typing.overload? (Outside stubs, that is.) Given that a short-term solution
is already possible using a stub, I'm not sure that adding another
short-term solution is worth it, if we don't intend to keep it around.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151025/21c88824/attachment.html>