[Python-ideas] PEP 484 change proposal: Allowing @overload outside stub files

[Andrew Barnert]

On Jan 22, 2016, at 12:00, Guido van Rossum <guido at python.org> wrote:
> 
> Ben Darnell (Tornado lead) brought up a good use case for allowing @overload in regular Python files.
> 
> There's some discussion (some old, some new) here: https://github.com/ambv/typehinting/issues/72
> 
> I now propose to allow @overload in non-stub (i.e. .py) files, but with the following rule: a series of @overload-decorated functions must be followed by an implementation function that's not @overload-decorated. Calling an @overload-decorated function is still an error (I propose NotImplemented). Due to the way repeated function definitions with the same name replace each other, leaving only the last one active, this should work. E.g. for Tornado's utf8() the full definition would look like this:
> 
> @overload
> def utf8(value: None) -> None: ...
> @overload
> def utf8(value: bytes) -> bytes: ...
> @overload
> def utf8(value: str) -> bytes: ...  # or (unicode)->bytes, in PY2
> def utf8(value):
>     # Real implementation goes here.
It feels like this is too similar to single_dispatch to be so different in details. I get the distinction (the former is for a function that has a single implementation but acts like a bunch of overloads that switch on type, the latter is for a function that's actually implemented as a bunch of overloads that switch on type), and I also get that it'll be much easier to extend overload to compile-time multiple dispatch than to extend single_dispatch to run-time multiple dispatch (and you don't want the former to have to wait on the latter), and so on. But it still feels like someone has stapled together two languages here.

(Of course I feel the same way about typing.protocols and implicit ABCs, and I know you disagreed there, so I wouldn't be too surprised if you disagree here as well. But this is even _more_ of a distinct and parallel system than that was--at least typing.Sized is in some way related to collections.abc.Sized, while overload is not related to single_dispatch at all, so someone who finds the wrong one in a search seems much more liable to assume that Python just doesn't have the one he wants than to find it.)

Other than that detail, I like everything else: some feature like this should definitely be part of the type checker (the only alternative is horribly complex type annotations); if it's allowed in stub files, it should be allowed in source files; and the rule of "follow the overloads with the real implementation" seems like by far the simplest rule that could make this work.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160122/eaffebcf/attachment.html>