[issue39391] Nondeterministic Pydoc output on functions that have functions as default parameters
New submission from Peter Occil <poccil14@gmail.com>: It appears that if a method has default parameters set to functions, as in this example: def f1(): pass def f2(a, b=f1): pass The resulting Pydoc output produces a different, nondeterministic rendering for the f2 method each time it generates the documentation, such as `m1(a, b=<function f1 at 0x7f4ff67f8950>)` or `m1(a, b=<function f1 at 0x7f4ff67f8950>)`. And this is problematic for version control systems, among other things, especially since this is not a meaningful change to the documentation. One solution may be to write, say, `m1(a, b=f1)` instead. ---------- assignee: docs@python components: Documentation messages: 360278 nosy: Peter Occil, docs@python priority: normal severity: normal status: open title: Nondeterministic Pydoc output on functions that have functions as default parameters type: behavior _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Ammar Askar <ammar@ammaraskar.com> added the comment: See also: https://bugs.python.org/issue37645 which discusses changing the string representation of functions to omit the address. ---------- nosy: +ammar2 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment: You will get the same problem for common idiom of using a singleton for optional parameters without default value. _singleton = object() def get(key, default=_signleton): if default is _signleton: ... And for other objects whos repr contains "at 0x...". And even more complex problem with sets. When test the pydoc output, ignore non-deterministic parts. For example, doctest allows you to use a placeholder.
C() #doctest: +ELLIPSIS <__main__.C instance at 0x...>
---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Peter O. <poccil14@gmail.com> added the comment: No, the use case I have in mind is storing outputs of the pydoc3 program -- as is -- in version control systems such as Git (e.g., running a command like "pydoc3 mymodule > mymodule_doc.txt"). The pydoc3 output is not further parsed by programs, or even "tested". For example, adding "#doctest: +ELLIPSIS" as in the following example does not solve the problem in the opening post: def testfunc(a, m=d0): #doctest: +ELLIPSIS pass ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Andrew Svetlov <andrew.svetlov@gmail.com> added the comment: Serhiy is right, I doubt if we can do something here. A function address is a part of its __repr__() output. ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Serhiy Storchaka <storchaka+cpython@gmail.com> added the comment: Even if we change the repr of functions (I like this idea), this will not solve the general problem: many reprs contain an object id. In your case I suggest to post-process the pydoc output and replace parts matching ' at 0x[0-9a-fA-F]+'. ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: repr(f2) is not 'non-deterministic'. If one runs it again for the same function object, one gets the same answer. It only changes when one starts over and creates a new function object with the same name but (usually) different id. I think it appropriate that the default object representation include the object id. It may help with debugging or other operations. I agree that pydoc output with run-dependent ids may not be suitable for storage in version control. Either remove or normalize them yourself or ask the pydoc developers to add an option to improve its output. Reclosing. ---------- nosy: +terry.reedy resolution: -> third party status: open -> closed title: Nondeterministic Pydoc output on functions that have functions as default parameters -> Run-dependent Pydoc output for functions default parameters _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Peter O. <poccil14@gmail.com> added the comment: Is this bug tracker the correct place to "ask the pydoc developers to add an option to improve [the Pydoc] output", in the sense that the option doesn't write out object IDs? If not, where is the correct place to do so? ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
Terry J. Reedy <tjreedy@udel.edu> added the comment: Sorry, I was thinking of something else when I closed this. What you want is a new -x option, for some 'x'. The following would help, especially as there is no one who specifically maintains pydoc. a) a specific proposal or set of proposals as to what letter to use for the option and what the result should be. b) a currently failing test case (based on the above). c. a patch for test.test_pydoc adding the test, preferably self-contained (no added file) -- or does any current test already involve an 'at 0xnnnnnnnn' output? d. a patch for pydoc.py making the test pass. ---------- resolution: third party -> stage: resolved -> test needed status: closed -> open title: Run-dependent Pydoc output for functions default parameters -> Pydoc: add option to remove run-specific ids (addresses) type: behavior -> enhancement versions: +Python 3.9 _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue39391> _______________________________________
participants (6)
-
Ammar Askar -
Andrew Svetlov
-
Peter O.
-
Peter Occil
-
Serhiy Storchaka
-
Terry J. Reedy