RetroSearch Browse

Fri Oct 23 11:38:30 EDT 2015 · http://mail.python.org/pipermail/python-dev/2015-October/142027.html

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.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   |   ncoghlan at gmail.com   |   Brisbane, Australia

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2015-October/142027.html below:

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