A RetroSearch Logo

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

Search Query:

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

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

[Python-Dev] PEP 484 -- proposal to allow @overload in non-stub filesRandom832 random832 at fastmail.com
Wed Oct 21 21:45:56 EDT 2015
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.

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.

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4