(original) (raw)
On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 22 October 2015 at 19:51, Guido van Rossum <guido@python.org> wrote:
\> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <greg@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):
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.