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

[Gregory P. Smith]

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.

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?

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.

-gps


>
>> How about this to allow overloads to have actual implementations?
>>
>> @overloaded
>> def __getitem__(self, x):
>>     <default implementation, if none of the overloads matched>
>>
>> @overloaded returns a function which will check the types against the
>> overloads (or anyway any overloads that have actual implementations),
>> call them returning the result if applicable, otherwise call the
>> original function.
>>
>> Some magic with help() would improve usability, too - it could print all
>> the overloads and their docstrings.  Maybe even @overload('__getitem__')
>> def __get_int(self, i: int), to make it so order doesn't matter.
>>
>> That just leaves the question of how's this all gonna work with
>> subclasses.
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>>
> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20151022/23abd4a6/attachment.html>