[issue15527] Double parents in functions references
New submission from Serhiy Storchaka: :c:func:`PyMem_Malloc(n)` on Doc/c-api/memory.rst:109 rendered in HTML as <tt class="xref c c-func docutils literal"><span class="pre">PyMem_Malloc(1)()</span></tt> (note double parents). There are many other examples on this and other pages. The issue is actual for all modern versions of Python. ---------- assignee: docs@python components: Documentation messages: 167137 nosy: docs@python, storchaka priority: normal severity: normal status: open title: Double parents in functions references versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Changes by Antoine Pitrou <pitrou@free.fr>: ---------- title: Double parents in functions references -> Double parens in functions references _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Changes by Andrew Svetlov <andrew.svetlov@gmail.com>: ---------- nosy: +asvetlov _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Andrew Svetlov added the comment: Fixed. Sorry, I forgot to mention issue number in commit messages. So it's 9c99f31a9c2a 96cc3ab243e5 and 1e8f6d8e5c0e commits. Thanks for report. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Georg Brandl added the comment: These commit hashes don't seem to match this issue. ---------- nosy: +georg.brandl _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Andrew Svetlov added the comment: Sorry, Georg. A'm apologizing. Actual commit numbers are: 6dab233a115e a979b005a814 4787b9b2f860 ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Georg Brandl added the comment: Thanks! ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Andrew Svetlov added the comment: Thank you for reviewing every minor update. It's a big deal and heavy work! ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Serhiy Storchaka added the comment: Hmm, I'm hoping that will be fixed by fixing of some markup words (:c:func:, :func:, :meth:, etc) processing, and not that they will simply be removed. :c:func: works only for function name without parameters or for function name with empty list of parameters inside the parentheses (:c:func:`PyMem_Malloc`, :c:func:`PyMem_Malloc()`, but not :c:func:`PyMem_Malloc(1)`). :c:macro: works also for non-empty list (:c:macro:`Py_CLEAR(obj)` for example). And Doc/c-api/memory.rst is not only one issue file. The list of suspicious places you can get by the followed command: find Doc/ -type f -name '*.rst' -exec egrep -n --color ':`\w+[(][^)]' '{}' + ---------- resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Georg Brandl added the comment: The markup you mentioned will not be changed: these are two different usecases. Either you link to the function itself (:func:`blah`), or you show a piece of code (``blah(n)``). ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Andrew Svetlov added the comment:
From my perspective sphinx doesn't allow notations like :c:func:`PyMem_Malloc(1)` Do you want to publish bugfix for sphinx? Sounds like good idea, but that fix is out my current competence. I just fixed weird stuff which you pointed out. If you want to do more — you are welcome. Please push a patch.
---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Serhiy Storchaka added the comment: Sorry, I don't know anything about the Sphinx, therefore, I do not know what is the problem and what the solution should be. 1) If this is the improper use of markup (the arguments are not supported and must not), we need to remove markup from other doc files (Doc/library/os.rst, Doc/library/platform.rst, Doc/library/unittest.rst, Doc/whatsnew/2.0.rst, Doc/whatsnew/2.1.rst, Doc/whatsnew/2.2.rst, Doc/whatsnew/2.3.rst, Doc/whatsnew/2.4.rst, Doc/whatsnew/2.5.rst, Doc/whatsnew/3.0.rst). 2) If the behaviour of the markup is controlled by configuration files, which are under the management of the CPython team, then these configuration files should be fixed. 3) If the behaviour of the markup is hardcoded inside the Sphinx, then it is the Sphinx bug and it should be reported to Sphinx team. I don't know what CPython team can/should do with it. Which of these variants is actual? Note, :c:macro: works for names with arguments, and :c:func:, :func:, :meth: did not. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Georg Brandl added the comment: 1) is correct. (And cmacro works because it's only for non-function macros anyway.) ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Chris Jerdonek added the comment: - a distinct non-*NULL* pointer if possible, as if :c:func:`PyMem_Malloc(1)` had + a distinct non-*NULL* pointer if possible, as if ``PyMem_Malloc(1)`` had
From my perspective sphinx doesn't allow notations like :c:func:`PyMem_Malloc(1)`
I believe that it does. Sphinx allows you to specify link text distinct from the target for various roles: http://docs.python.org/devguide/documenting.html#id3 So for the above, it would be-- :c:func:`PyMem_Malloc(1) <PyMem_Malloc>` I confirmed that this works. I think this is preferable to displaying the preferred text without any hyperlink. ---------- nosy: +cjerdonek _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Serhiy Storchaka added the comment: Thanks Chris. Here's the patch. ---------- stage: needs patch -> patch review _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Changes by Serhiy Storchaka <storchaka@gmail.com>: ---------- keywords: +patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Changes by Serhiy Storchaka <storchaka@gmail.com>: Added file: http://bugs.python.org/file26760/doc_dbl_parens.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Georg Brandl added the comment: Is anyone even reading my messages...? ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Serhiy Storchaka added the comment: Georg, I see that :meth: with arguments works in the form :meth:`name(args) <module.class.name>`. I believe that the hyperlinks are helpful and it was designed that way. Replacing :meth:/:func:/:c:func: for names with arguments on double backquotes can be done almost automatically. Here's another patch (I like it less). ---------- Added file: http://bugs.python.org/file26763/doc_dbl_parens_drop_markup.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Roundup Robot added the comment: New changeset 5e025dc7d728 by Andrew Svetlov in branch 'default': Issue #15527: fix docs, remove double parens by changing markup. http://hg.python.org/cpython/rev/5e025dc7d728 ---------- nosy: +python-dev _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Andrew Svetlov added the comment: Applied patch uses ``expr(n)`` as Georg prefer. Serhiy, please close the issue if you have not any upcoming patches. Thanks. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Serhiy Storchaka added the comment: Thank you Andrew. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
Roundup Robot added the comment: New changeset be4da80b493e by Martin Panter in branch '2.7': Issue #15527: remove double parens by changing markup. https://hg.python.org/cpython/rev/be4da80b493e ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue15527> _______________________________________
participants (6)
-
Andrew Svetlov -
Antoine Pitrou
-
Chris Jerdonek
-
Georg Brandl
-
Roundup Robot
-
Serhiy Storchaka