Chaim Gewirtz added the comment:
Interesting. PyCharm has no problem with this code. It also autocompletes the
argument names for me, which is very useful, especially since there a dozen
different Child classes.
Isn't "Simple is better than complex", and doesn't "...pr
Chaim Gewirtz added the comment:
What is better?
A. Keeping Python as is, with four separate signature declarations (1x Parent,
2x @overload Child, and 1x actual signature in Child), and a second method call
overhead at runtime (to satisfy mypy as it exists now).
--or--
B. Simplify Python
Chaim Gewirtz added the comment:
Thanks for your perspective.
To summarize here is how my proposed enhancement might look in practice:
class Parent:
def foo(self, **kwargs):
"""Argument names of foo vary depending on the child class."""
clas
Chaim Gewirtz added the comment:
"The purpose of `@overload` is quite different." So, this would overload the
@overload decorator. Hmmm...
Is there a better way to accomplish this goal? What would you suggest, a new
decorator?
--
Chaim Gewirtz added the comment:
In your example, does Child foo call Parent foo? Because the intent is to use
the parent's foo method.
--
___
Python tracker
<https://bugs.python.org/issue42
Chaim Gewirtz added the comment:
To clarify, this is how it's being done now a dozen times in actual production
code:
class Child(Parent):
@overload foo(a, b): ...
def overload(**kwargs):
return super().foo(**kwargs)
The goal of this proposed enhancement is to remove two
New submission from Chaim Gewirtz :
Why should @overload need to be followed by an implementation when an
implementation already exists in the parent class?
Illustrative example:
class Parent:
def foo(**kwargs):
"""Argument names of foo vary depending on
