[issue21818] cookielib documentation references Cookie module, not cookielib.Cookie class
New submission from Angus Taggart: all the links to Cookie class in the cookielib documentation point to Cookie module. for example: CookieJar.set_cookie(cookie) Set a *Cookie*, without checking with policy to see whether or not it should be set. cookie in the documentation links to https://docs.python.org/2/library/cookie.html#module-Cookie cookie in the documentation should link to https://docs.python.org/2/library/cookielib.html#cookielib.Cookie ---------- assignee: docs@python components: Documentation messages: 221133 nosy: Ajtag, docs@python priority: normal severity: normal status: open title: cookielib documentation references Cookie module, not cookielib.Cookie class versions: Python 2.7 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Changes by Demian Brecht <demianbrecht@gmail.com>: ---------- nosy: +dbrecht _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Serhiy Storchaka added the comment: Georg, this looks as a bug in Sphinx configuration. Why module takes priority on class when the role is explicitly specified? I have counted about two hundreds of similar bugs in the documentation. ---------- nosy: +georg.brandl, serhiy.storchaka type: -> behavior _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Serhiy Storchaka added the comment: Here is a patch for 2.7 that fixes above a hundred of broken class references. But may be even more broken function references. I think it would be better to fix Sphinx rules. ---------- keywords: +patch priority: normal -> high Added file: http://bugs.python.org/file38485/docs_class_links-2.7.patch _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
R. David Murray added the comment: This happens because the role is pretty much ignored by Sphinx for linking purposes. I remember Georg talking about the reason for this, but I forget what it was. Perhaps it would be possible to, as you suggest, have the roll affect the priority...but it may be the case that the references don't currently retain the needed information. Regardless, that would be an issue for the Sphinx tracker. ---------- nosy: +r.david.murray _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Serhiy Storchaka added the comment: Georg, is it possible to tune Sphinx rules? ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Georg Brandl added the comment: The rules are as they are mostly for backwards compatibility. But it is rarely a problem since there is only one object with a given name. :class:`Cookie` within the docs for cookielib would not be able to link to Cookie.Cookie since it is not found in its scope. :class:`Cookie.Cookie` works, as does :class:`~Cookie.Cookie`. When you use the "find-in-any-namespace" syntax, i.e. :class:`.Cookie` the type *will* be taken into account. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Serhiy Storchaka added the comment: Thus the only way to fix links is to specify full names? Does docs_class_links-2.7.patch look good to you? ---------- stage: -> patch review _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Roundup Robot added the comment: New changeset 5b40d81e8883 by Serhiy Storchaka in branch '2.7': Issue #21818: Fixed references to classes that have names matching with module https://hg.python.org/cpython/rev/5b40d81e8883 New changeset d64e37b9204e by Serhiy Storchaka in branch '3.5': Issue #21818: Fixed references to classes that have names matching with module https://hg.python.org/cpython/rev/d64e37b9204e New changeset 62c9a89a2103 by Serhiy Storchaka in branch '3.6': Issue #21818: Fixed references to classes that have names matching with module https://hg.python.org/cpython/rev/62c9a89a2103 New changeset c642c597d05c by Serhiy Storchaka in branch 'default': Issue #21818: Fixed references to classes that have names matching with module https://hg.python.org/cpython/rev/c642c597d05c ---------- nosy: +python-dev _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Cheryl Sabella added the comment: Can this issue be closed? ---------- nosy: +csabella _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
Changes by Berker Peksag <berker.peksag@gmail.com>: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue21818> _______________________________________
participants (8)
-
Angus Taggart -
Berker Peksag
-
Cheryl Sabella
-
Demian Brecht
-
Georg Brandl
-
R. David Murray
-
Roundup Robot
-
Serhiy Storchaka