I've thought this over and I don't think it's worth it. We need to wait for
a working proposal for multi-dispatch first. Otherwise we'll just end up
having to support this interim syntax *and* whatever the new multi-dispatch
is. Keeping @overload restricted to stub files makes it much more tractable.
On Thu, Oct 22, 2015 at 10:51 AM, Guido van Rossum <gu...@python.org> wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <g...@krypto.org> wrote:
>
>>
>>
>> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum <gu...@python.org>
>> wrote:
>>
>>> Well the whole point is not to have to figure out how to implement that
>>> right now.
>>>
>>> On Wed, Oct 21, 2015 at 6:45 PM, Random832 <random...@fastmail.com>
>>> wrote:
>>>
>>>> Guido van Rossum <gu...@python.org> writes:
>>>> > The proposal is to allow this to be written as follows in
>>>> > implementation (non-stub) modules:
>>>> >
>>>> > class Foo(Generic[T]):
>>>> > @overload
>>>> > def __getitem__(self, i: int) -> T: ...
>>>> > @overload
>>>> > def __getitem__(self, s: slice) -> Foo[T]: ...
>>>> > def __getitem__(self, x):
>>>> > <actual implementation goes here>
>>>> >
>>>> > The actual implementation must be last, so at run time it will
>>>> > override the definition.
>>>>
>>>
>> I think this *could* be fine. It is certainly readable. And, as is
>> already possible in .pyi files, more accurately expressive than the Union
>> which doesn't imply a parameter type to return value type relationship.
>>
>
> Right, which is how this got started.
>
>
>> 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).
>
> We could also wait for a multidispatch PEP to land -- but I'm worried that
> we'll be waiting past 3.6.
>
> Then again I don't see how true multidispatch would be able to deal with
> the syntax proposed here -- you need some kind of decorator on the fallback
> implementation.
>
>
>> Note that it would also slow down module import time as the code for each
>> of the earlier ... definitions with annotation structures and @overload
>> decorator calls is executed, needlessly creating objects and structures
>> that are immediately discarded upon each subsequent definition.
>>
>
> Yes, but I don't think this is going to make a noticeable difference.
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
--
--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
