[issue30052] URL Quoting page links to function Bytes instead of defintion

New submission from Cheryl Sabella: On the URL Quoting page, the following line: `string may be either a str or a bytes.` Has the `str` link to: https://docs.python.org/3/library/stdtypes.html#str But the `bytes` link to: https://docs.python.org/3/library/functions.html#bytes Should the `bytes` link to? https://docs.python.org/3/library/stdtypes.html#bytes ---------- assignee: docs@python components: Documentation messages: 291546 nosy: csabella, docs@python priority: normal severity: normal status: open title: URL Quoting page links to function Bytes instead of defintion versions: Python 3.6 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella added the comment: I've looked into this a little more and it seems that, in all instances, the :class:`bytes` and :class:`bytearray` mark-up link to the Built-In Functions page instead of the Built-In Types page. It also looks like the Built-In Functions page has specific code for many types (dict, frozenset, memoryview, list, tuple, str, etc) so that it wouldn't link to this (the functions) page. However, bytes and bytearray aren't part of that list. I don't know if they were excluded on purpose or if their links should behave like the other types. Please let me know if this should change. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella added the comment: Since no one has said that this change shouldn't be made, I'll start working on this. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Serhiy Storchaka <storchaka+cpython@gmail.com>: ---------- nosy: +georg.brandl _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Cheryl Sabella <chekat2@gmail.com>: ---------- pull_requests: +1382 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Mariatta Wijaya <mariatta.wijaya@gmail.com>: ---------- stage: -> patch review versions: +Python 3.7 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Nick Coghlan added the comment: New changeset c6db4811f9ea3aeff0e1fafe1c60a22835ef359e by Nick Coghlan (csabella) in branch 'master': bpo-30052: Link `bytes` & `bytearray` to stdtypes not functions (GH-1271) https://github.com/python/cpython/commit/c6db4811f9ea3aeff0e1fafe1c60a22835e... ---------- nosy: +ncoghlan _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Berker Peksag <berker.peksag@gmail.com>: ---------- stage: patch review -> backport needed type: -> behavior _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella added the comment: FYI. When I tested this change locally, I needed to do a 'make clean' then a 'make html' for all the pages to relink to the stdtypes page for :class:`bytes`. I had asked on the IRC channel about that and thought maybe the merge into the master would do that automatically, but checking some of the links (like on the urllib.parse page), it didn't update them. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Nick Coghlan added the comment: Indeed, checking the dev build at https://docs.python.org/dev/library/urllib.parse.html#url-quoting shows it still linking to the old location. Perhaps the `autobuild-dev-html` target in the Makefile should be adding `-E` and `-a` so it always regenerates everything, rather than re-using the potentially stale cached info from the previous day? ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella added the comment: I don't think it would add a lot of time or processing to rebuild it daily, would it? Seems safer than not doing it. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Nick Coghlan <ncoghlan@gmail.com>: ---------- pull_requests: +1450 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Nick Coghlan added the comment: New PR disabling the output caching and adding a corresponding NEWS entry: https://github.com/python/cpython/pull/1339 On my local machine, it takes a "nothing changed" build from less than 2 seconds to just under 2 minutes, but I think that's fine for a daily build task. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Mariatta Wijaya <mariatta.wijaya@gmail.com>: ---------- pull_requests: +1995 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Mariatta Wijaya added the comment: New changeset 1c92c0edca413c6f8ce8ec326a67451ae751ead9 by Mariatta in branch '3.6': bpo-30052: Link `bytes` & `bytearray` to stdtypes not functions (GH-1271) (GH-1915) https://github.com/python/cpython/commit/1c92c0edca413c6f8ce8ec326a67451ae75... ---------- nosy: +Mariatta _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella added the comment: Sorry, Mariatta. I didn't realize this was waiting for a backport. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Nick Coghlan added the comment: New changeset 7a82f9c2b94d31c8f4cc8bb8e3151765d8b148d7 by Nick Coghlan in branch 'master': bpo-30052: Always regenerate cross-references (#1339) https://github.com/python/cpython/commit/7a82f9c2b94d31c8f4cc8bb8e3151765d8b... ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Changes by Nick Coghlan <ncoghlan@gmail.com>: ---------- pull_requests: +1999 _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Nick Coghlan added the comment: Not your fault, Cheryl! I unfortunately got distracted and didn't follow up on the backports for several PRs I merged a while back. Mariatta has been graciously cleaning some of those up rather than leaving them lingering the way I had been :) I also just noticed that I never merged the PR to always regenerate the cross-references, so I went ahead and did that, and also submitted the corresponding 3.6 backport PR. ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Mariatta Wijaya added the comment: New changeset 798cfb212383a6f5a31b610825d1af1d376804b2 by Mariatta (Nick Coghlan) in branch '3.6': bpo-30052: Always regenerate cross-references (GH-1339) (GH-1921) https://github.com/python/cpython/commit/798cfb212383a6f5a31b610825d1af1d376... ---------- _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

Mariatta Wijaya added the comment: Backport PR looks good so I went ahead and merged it :) Thanks. ---------- resolution: -> fixed stage: backport needed -> resolved status: open -> closed _______________________________________ Python tracker <report@bugs.python.org> <http://bugs.python.org/issue30052> _______________________________________

wim glenn <wim.glenn@gmail.com> added the comment: https://docs.python.org/3/library/functions.html Usually the little paragraph icon appears when you hover over a function name, giving an anchor link. It's not doing it for bytes or bytearray. Was that an unintended consequence of disambiguation from the stdtypes html? ---------- nosy: +wim.glenn _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue30052> _______________________________________

wim glenn <wim.glenn@gmail.com> added the comment: This anchor works, by the way: https://docs.python.org/3/library/functions.html#func-bytes Hopefully someone more fluent in the docs syntax can figure out a way to fix the anchor-link hovers ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue30052> _______________________________________

Cheryl Sabella <cheryl.sabella@gmail.com> added the comment: Hi @wim.glenn, Thanks for the report. It looks like the same issue applies to all the built-in functions that are handled this way, not just bytearray and bytes. So, dict, frozenset, list, memoryview, range, set, str, and tuple too. I'm not sure what the fix is, but I agree that we should take a look. Can you create a new tracker issue for this? Thanks! ---------- _______________________________________ Python tracker <report@bugs.python.org> <https://bugs.python.org/issue30052> _______________________________________
participants (6)
-
Berker Peksag
-
Cheryl Sabella
-
Mariatta Wijaya
-
Nick Coghlan
-
Serhiy Storchaka
-
wim glenn