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.
Leaving the "@overload" out thus indicates that the definition is an
implementation of the preceding type based dispatch declaration,
rather than a new overload.
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.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
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
