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

[Guido van Rossum]

On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <greg at krypto.org> wrote:

>
>
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum <guido at 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 <random832 at fastmail.com>
>> wrote:
>>
>>> Guido van Rossum <guido at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151022/0fcfe095/attachment.html>