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

Guido van Rossum guido at python.org
Sun Oct 25 18:54:13 EDT 2015

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.gettypehints() 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): If we did this, the implied annotation on the last method would be: @overload def getitem(self, x: Any) -> Any: 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>

More information about the Python-Dev mailing list