But the user could have had the false impression that additional kwargs could be given when instantiating A. Obviously they are purely there for getting the init in the MRO working with multiple inheritance.

This just isn't true. You often do things with the kargs before passing them or other values to super. By using **kargs in the constructor and the call to `super`, you are indicating that the signature passes through, but there are many other things you could do instead. The docs *should* show that the derived method takes the same args as the inherited one it overrides. That is very useful information that belongs there. Best, -- Carl Smith carl.input@gmail.com On 26 May 2018 at 01:06, Michael Lohmann <mial.lohmann+pythonml@gmail.com> wrote:

Hi!

***Disclaimer: I am relatively new to Python***

I propose to add some mechanism that can automatically collect everything what would normally be collected by **kwargs in the __init__ method and directly pass it through to the super().__init__ call without being accessible in the __init__ itself. This way the autocompletion/docstring generation could safely ignore this argument which before would have showed up as **kwargs.

I believe that this could greatly enhance the readability of automated documentation and especially the autocomplete of an IDE.

I would like something like this to work:

class A: @pass_through_kwargs # like this? Or maybe __init__(self, a_value, ***pass_through_kwargs)? def __init__(self, a_value): super().__init__() # <- realize that nothing is passed in here

class B: def __init__(self, some_value): pass

class MyClass(A, B): def __init__(self): super().__init__(a_value=1, some_value=2)

Where the autocomplete of `A(` shows me just `A(a_value)`. The pass_through_kwargs can safely be ignored, since it is not "a real input" of A. It is automatically merged with the parameters of the `super(A, self).__init__()` call. How exactly this should be done would have to be discussed in more detail (I guess the actual values should probably override the passed through ones).

With the current python version the code would have looked like

class A: def __init__(self, a_value, **kwargs): super().__init__(**kwargs)

But the user could have had the false impression that additional kwargs could be given when instantiating A. Obviously they are purely there for getting the init in the MRO working with multiple inheritance.

One could also add something like pass_through_args as well but the usability of that is probably much more limited.

Could this even work in theory? I guess it might be quite tricky since `super().__init__` doesn't even have to be called. If that would be the case: should it be called automatically if pass_through_kwargs were given after the init is done?

By the way: Thank you all for this amazing language! Cheers, Michael

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

But the user could have had the false impression that additional kwargs could be given when instantiating A. Obviously they are purely there for getting the init in the MRO working with multiple inheritance.

This just isn't true. You often do things with the kargs before passing them or other values to super. By using **kargs in the constructor and the call to `super`, you are indicating that the signature passes through, but there are many other things you could do instead. The docs *should* show that the derived method takes the same args as the inherited one it overrides. That is very useful information that belongs there. Best, -- Carl Smith carl.input@gmail.com On 26 May 2018 at 01:06, Michael Lohmann <mial.lohmann+pythonml@gmail.com> wrote:

Hi!

***Disclaimer: I am relatively new to Python***

I propose to add some mechanism that can automatically collect everything what would normally be collected by **kwargs in the __init__ method and directly pass it through to the super().__init__ call without being accessible in the __init__ itself. This way the autocompletion/docstring generation could safely ignore this argument which before would have showed up as **kwargs.

I believe that this could greatly enhance the readability of automated documentation and especially the autocomplete of an IDE.

I would like something like this to work:

class A: @pass_through_kwargs # like this? Or maybe __init__(self, a_value, ***pass_through_kwargs)? def __init__(self, a_value): super().__init__() # <- realize that nothing is passed in here

class B: def __init__(self, some_value): pass

class MyClass(A, B): def __init__(self): super().__init__(a_value=1, some_value=2)

Where the autocomplete of `A(` shows me just `A(a_value)`. The pass_through_kwargs can safely be ignored, since it is not "a real input" of A. It is automatically merged with the parameters of the `super(A, self).__init__()` call. How exactly this should be done would have to be discussed in more detail (I guess the actual values should probably override the passed through ones).

With the current python version the code would have looked like

class A: def __init__(self, a_value, **kwargs): super().__init__(**kwargs)

But the user could have had the false impression that additional kwargs could be given when instantiating A. Obviously they are purely there for getting the init in the MRO working with multiple inheritance.

One could also add something like pass_through_args as well but the usability of that is probably much more limited.

Could this even work in theory? I guess it might be quite tricky since `super().__init__` doesn't even have to be called. If that would be the case: should it be called automatically if pass_through_kwargs were given after the init is done?

By the way: Thank you all for this amazing language! Cheers, Michael

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/