[issue42812] @overload-ing method of parent class without actual implementation

Guido van Rossum added the comment: I hesitate to add anything because you are exposing so much confusion. May I suggest that you ask about this on a user group first before proposing a new feature? One place that makes sense given that this is a type system feature would be this Gitter chan

[issue42812] @overload-ing method of parent class without actual implementation

Change by Terry J. Reedy : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue42812] @overload-ing method of parent class without actual implementation

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.""" class Child(Parent): @overload def

[issue42812] @overload-ing method of parent class without actual implementation

Yurii Karabas <1998uri...@gmail.com> added the comment: > What is better? Sorry, I can't answer this question. I am a regular python user and I just tried to help with your issue. I believe we should wait for someone from core team to answer this question. > In your example, does Child foo

[issue42812] @overload-ing method of parent class without actual implementation

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 ___

[issue42812] @overload-ing method of parent class without actual implementation

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

[issue42812] @overload-ing method of parent class without actual implementation

Yurii Karabas <1998uri...@gmail.com> added the comment: I think the simplest solution in your case is not to use `@overload`, as far as I understand you want to override the signature of base method. This code won't produce any error when used with `mypy`: ``` class Parent: def foo(**kwarg

[issue42812] @overload-ing method of parent class without actual implementation

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 "...practicality beat purity

[issue42812] @overload-ing method of parent class without actual implementation

Yurii Karabas <1998uri...@gmail.com> added the comment: `mypy` will produce an error on such code: ``` class Parent: def foo(self, **kwargs): """Argument names of foo vary depending on the child class.""" class Child(Parent): @overload def foo(self, a, b): pass

[issue42812] @overload-ing method of parent class without actual implementation

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 extr

[issue42812] @overload-ing method of parent class without actual implementation

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? -- ___ Python track

[issue42812] @overload-ing method of parent class without actual implementation

Yurii Karabas <1998uri...@gmail.com> added the comment: The purpose of `@overload` is quite different. I believe you thought that this is smth like `@override` in Java world but it different. Basically, the correct usage of `@overaload` is: ``` @overload def process(response: None) -> None:

[issue42812] @overload-ing method of parent class without actual implementation

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 the child class.""" class