<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 October 2015 at 19:51, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
</span><span class="">>> What would it Foo.__getitem__.__annotations__ contain in this situation?<br>
>> It'd unfortunately be an empty dict if implemented in the most trivial<br>
>> fashion rather than a dict containing your Unions... Do we care?<br>
><br>
> Initially it would indeed be {}. Once we have a true multi-dispatch PEP we<br>
> can iterate, both on how to spell it (perhaps the final __getitem__ needs an<br>
> @overload as well) and on what happens in the annotations (or at least, what<br>
> typing.get_type_hints() returns).<br>
<br>
</span>Just ensuring I understand the problem with using a third @overload in<br>
the spelling from the start:<br>
<span class=""><br>
    class Foo(Generic[T]):<br>
        @overload<br>
        def __getitem__(self, i: int) -> T: ...<br>
<br>
        @overload<br>
        def __getitem__(self, s: slice) -> Foo[T]: ...<br>
<br>
</span>        @overload<br>
<span class="">        def __getitem__(self, x):<br>
            <actual implementation goes here><br>
<br>
</span>If we did this, the implied annotation on the last method would be:<br>
<br>
    @overload<br>
    def __getitem__(self, x: Any) -> Any:<br>
        <actual implementation goes here><br>
<br>
which gets the signature wrong - this isn't an Any:Any mapping, it's a sequence.<br></blockquote><div><br></div><div>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.)<br><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Leaving the "@overload" out thus indicates that the definition is an<br>
implementation of the preceding type based dispatch declaration,<br>
rather than a new overload.<br></blockquote><div><br></div><div>Yeah, that was the proposal. But I no longer think it's worth it.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Assuming a future multidispatch implementation used<br>
"functools.multidispatch" as the decorator (to complement the existing<br>
functools.singledispatch) rather than "typing.overload", this seems<br>
like a reasonable short term solution to me.<br></blockquote></div><br></div><div class="gmail_extra">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.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>