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

[Terry Reedy]

On 1/22/2016 3:00 PM, Guido van Rossum 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,

 From a naive point of view, it is the prohibition that is exceptional 
and in need of justification.  So its removal would seem non-problematical.

 >  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.

Again, from a naive point of view, treating 'overload' the same as 'x', 
this seems wasteful, so the usage must be a consenting-adult tradeoff 
between the time taken to create function objects that get thrown away 
and the side-effect of 'overload'.

I do understand that non-beginners with expectation based on other 
languages, who don't know Pythons specific usage of 'overload', may get 
confused.

Your proposed implementation is missing a return statement.

def overload(func):
     def overload_dummy(*args, **kwds):
         raise NotImplemented(
             "You should not call an overloaded function. "
             "A series of @overload-decorated functions "
             "outside a stub module should always be followed "
             "by an implementation that is not @overloaded.")

To avoid throwing away two functions with each def, I suggested moving 
the constant replacement outside of overload.

def _overload_dummy(*args, **kwds):
     raise NotImplemented(
         "You should not call an overloaded function. "
         "A series of @overload-decorated functions "
         "outside a stub module should always be followed "
         "by an implementation that is not @overloaded.")

def overload(func):
     return _overload_dummy

> NOTE: If you are trying to understand why we can't use a stub file here
> or why we can't solve this with type variables or unions, please read
> the issue and comment there if things are not clear. Here on
> python-ideas I'd like to focus on seeing whether this amendment is
> non-controversial (apart from tea party members who just want to repeal
> PEP 484 entirely :-).

Sorry, I don't see any connection between tea party philosophy and type 
hinting, except maybe in the opposite direction.  Maybe we should 
continue leaving external politics, US or otherwise, out of pydev 
discussions.

> I know that previously we wanted to come up with a complete solution for
> multi-dispatch based on type annotations first, and there are
> philosophical problems with using @overload (though it can be made to
> work using sys._getframe()). The proposal here is *not* that solution.

It would be possible for _overload_dummy to add a reference to each func 
arg to a list or set thereof.  Perhaps you meant more or less the same 
with 'using sys._getframe()'.  The challenge would be writing a new 
'overload_complete' decorator, for the last function, that would combine 
the pieces.

-- 
Terry Jan Reedy