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:
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 _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3NPQMMWI... Code of Conduct: http://python.org/psf/codeofconduct/
-- Night gathers, and now my watch begins. It shall not end until my death.
Hi Victor, and thanks for you reply.
On 9 Feb 2021, at 11:46, Victor Stinner <vstinner@python.org> wrote: If there are applications relying on the parameter name, it's better to trust the Python implementation, rather than the documentation.
I feared that answer :)
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 :-(
Unfortunately, yes. Erlend
On 9 Feb 2021, at 11:22, Erlend Aasland <Erlend-A@innova.no> wrote:
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
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
Thanks, Jakub. E
On 9 Feb 2021, at 19:42, Jakub Stasiak <jakub@stasiak.at> wrote:
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.
On Tue., Feb. 9, 2021, 12:20 Serhiy Storchaka, <storchaka@gmail.com> wrote:
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
09.02.21 12:22, Erlend Aasland пише: 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.
I agree with Serhiy's logic. -Brett
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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JE2E5RJZ... Code of Conduct: http://python.org/psf/codeofconduct/
On 2/9/21 9:15 PM, Serhiy Storchaka wrote:
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.
It is. Python will correct you if you try to use the documented name:
import sqlite3 connection = sqlite3.connect(':memory:') connection.create_function('testfunc', num_params=1, func=lambda arg: None) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: function missing required argument 'narg' (pos 2)
On 10 Feb 2021, at 01:28, Petr Viktorin <encukou@gmail.com> wrote:
On 2/9/21 9:15 PM, Serhiy Storchaka wrote:
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
09.02.21 12:22, Erlend Aasland пише: 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.
It is. Python will correct you if you try to use the documented name:
Correct. However, I suspect that most users use positional arguments with these functions (since this is the first (?) report of the inconsistency) so I guess it's ok, in this case, to make the arguments positional only and normalise the argument naming. Erlend
participants (6)
-
Brett Cannon -
Erlend Aasland -
Jakub Stasiak -
Petr Viktorin -
Serhiy Storchaka -
Victor Stinner