On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 22 October 2015 at 19:51, Guido van Rossum <gu...@python.org> wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <g...@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)
_______________________________________________
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
