Signature discrepancies between documentation and implementation
Hi all, What's the recommended approach with issues like https://bugs.python.org/issue43094? Change the docs or the implementation? I did a quick search on bpo, but could not find similar past issues. Erlend
If there are applications relying on the parameter name, it's better to trust the Python implementation, rather than the documentation. It would be better to make these parameters positional only in the first place, but now it's too late for such backward incompatible change :-( Victor On Tue, Feb 9, 2021 at 11:43 AM Erlend Aasland <Erlend-A@innova.no> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.
To provide some context as you looked for issues on bpo: in the two I was involved in[1][2] the resolution was to update the documenttion to reflect the actual situation. Best, Jakub [1] https://bugs.python.org/issue42230 [2] https://bugs.python.org/issue38580
09.02.21 12:22, Erlend Aasland пише:
What's the recommended approach with issues like https://bugs.python.org/issue43094? Change the docs or the implementation? I did a quick search on bpo, but could not find similar past issues.
If the documentation and the C implemented function contradict about parameter name, we are free to treat the parameter as positional-only. User cannot pass the argument as keyword because the documented name does not work, and the real name is not exposed to the user. In this case, there are two similar functions, create_function() and create_aggregate(). Both are documented as having parameter "num_params", but real names are different: "narg" and "n_arg". It would be confusing to have different spelling of the same parameter in similar functions. I am sure that it would be difficult to remember how is it spelled in every case. Also, in Python terminology, the semantic of this name is the number of parameters, not the number of argument. So I think that in this particular case the chance of breaking some code is insignificant, but possible long-term harm of exposing bad parameter names may be significant.
If there are applications relying on the parameter name, it's better to trust the Python implementation, rather than the documentation. It would be better to make these parameters positional only in the first place, but now it's too late for such backward incompatible change :-( Victor On Tue, Feb 9, 2021 at 11:43 AM Erlend Aasland <Erlend-A@innova.no> wrote:
-- Night gathers, and now my watch begins. It shall not end until my death.
To provide some context as you looked for issues on bpo: in the two I was involved in[1][2] the resolution was to update the documenttion to reflect the actual situation. Best, Jakub [1] https://bugs.python.org/issue42230 [2] https://bugs.python.org/issue38580
09.02.21 12:22, Erlend Aasland пише:
What's the recommended approach with issues like https://bugs.python.org/issue43094? Change the docs or the implementation? I did a quick search on bpo, but could not find similar past issues.
If the documentation and the C implemented function contradict about parameter name, we are free to treat the parameter as positional-only. User cannot pass the argument as keyword because the documented name does not work, and the real name is not exposed to the user. In this case, there are two similar functions, create_function() and create_aggregate(). Both are documented as having parameter "num_params", but real names are different: "narg" and "n_arg". It would be confusing to have different spelling of the same parameter in similar functions. I am sure that it would be difficult to remember how is it spelled in every case. Also, in Python terminology, the semantic of this name is the number of parameters, not the number of argument. So I think that in this particular case the chance of breaking some code is insignificant, but possible long-term harm of exposing bad parameter names may be significant.
participants (6)
-
Brett Cannon -
Erlend Aasland -
Jakub Stasiak -
Petr Viktorin -
Serhiy Storchaka -
Victor Stinner