This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: URL Quoting page links to function Bytes instead of defintion
Type: behavior Stage: resolved
Components: Documentation Versions: Python 3.7, Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Mariatta, cheryl.sabella, docs@python, georg.brandl, ncoghlan, wim.glenn
Priority: normal Keywords:

Created on 2017-04-12 12:49 by cheryl.sabella, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 1271 merged cheryl.sabella, 2017-04-24 18:11
PR 1339 merged ncoghlan, 2017-04-28 09:30
PR 1915 merged Mariatta, 2017-06-02 04:41
PR 1921 merged ncoghlan, 2017-06-02 14:04
Messages (17)
msg291546 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-04-12 12:49
On the URL Quoting page, the following line:

`string may be either a str or a bytes.`

Has the `str` link to:

But the `bytes` link to:

Should the `bytes` link to?
msg291575 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-04-12 22:14
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.
msg292215 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-04-24 09:35
Since no one has said that this change shouldn't be made, I'll start working on this.
msg292301 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-04-26 05:47
New changeset c6db4811f9ea3aeff0e1fafe1c60a22835ef359e by Nick Coghlan (csabella) in branch 'master':
bpo-30052: Link `bytes` & `bytearray` to stdtypes not functions  (GH-1271)
msg292428 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-04-27 11:53

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.
msg292440 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-04-27 13:35
Indeed, checking the dev build at 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?
msg292484 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-04-27 21:14
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.
msg292520 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-04-28 09:33
New PR disabling the output caching and adding a corresponding NEWS entry:

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.
msg294982 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2017-06-02 04:56
New changeset 1c92c0edca413c6f8ce8ec326a67451ae751ead9 by Mariatta in branch '3.6':
bpo-30052: Link `bytes` & `bytearray` to stdtypes not functions  (GH-1271) (GH-1915)
msg295015 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2017-06-02 13:03
Sorry, Mariatta.  I didn't realize this was waiting for a backport.
msg295019 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-06-02 13:30
New changeset 7a82f9c2b94d31c8f4cc8bb8e3151765d8b148d7 by Nick Coghlan in branch 'master':
bpo-30052: Always regenerate cross-references (#1339)
msg295020 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2017-06-02 14:05
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.
msg295229 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2017-06-06 02:19
New changeset 798cfb212383a6f5a31b610825d1af1d376804b2 by Mariatta (Nick Coghlan) in branch '3.6':
bpo-30052: Always regenerate cross-references (GH-1339) (GH-1921)
msg295230 - (view) Author: Mariatta (Mariatta) * (Python committer) Date: 2017-06-06 02:20
Backport PR looks good so I went ahead and merged it :)
msg345881 - (view) Author: wim glenn (wim.glenn) * Date: 2019-06-17 17:23

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?
msg345882 - (view) Author: wim glenn (wim.glenn) * Date: 2019-06-17 17:25
This anchor works, by the way:

Hopefully someone more fluent in the docs syntax can figure out a way to fix the anchor-link hovers
msg346253 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python committer) Date: 2019-06-21 21:27
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!
Date User Action Args
2022-04-11 14:58:45adminsetgithub: 74238
2019-06-21 21:27:29cheryl.sabellasetmessages: + msg346253
2019-06-17 17:25:28wim.glennsetmessages: + msg345882
2019-06-17 17:23:43wim.glennsetnosy: + wim.glenn
messages: + msg345881
2017-06-06 02:20:48Mariattasetstatus: open -> closed
resolution: fixed
messages: + msg295230

stage: backport needed -> resolved
2017-06-06 02:19:41Mariattasetmessages: + msg295229
2017-06-02 14:05:23ncoghlansetmessages: + msg295020
2017-06-02 14:04:24ncoghlansetpull_requests: + pull_request1999
2017-06-02 13:30:59ncoghlansetmessages: + msg295019
2017-06-02 13:03:21cheryl.sabellasetmessages: + msg295015
2017-06-02 04:56:26Mariattasetnosy: + Mariatta
messages: + msg294982
2017-06-02 04:41:43Mariattasetpull_requests: + pull_request1995
2017-04-28 09:33:44ncoghlansetmessages: + msg292520
2017-04-28 09:30:14ncoghlansetpull_requests: + pull_request1450
2017-04-27 21:14:32cheryl.sabellasetmessages: + msg292484
2017-04-27 13:35:18ncoghlansetmessages: + msg292440
2017-04-27 11:53:43cheryl.sabellasetmessages: + msg292428
2017-04-27 10:04:34berker.peksagsettype: behavior
stage: patch review -> backport needed
2017-04-26 05:47:04ncoghlansetnosy: + ncoghlan
messages: + msg292301
2017-04-25 01:54:13Mariattasetstage: patch review
versions: + Python 3.7
2017-04-24 18:11:52cheryl.sabellasetpull_requests: + pull_request1382
2017-04-24 12:22:00serhiy.storchakasetnosy: + georg.brandl
2017-04-24 09:35:38cheryl.sabellasetmessages: + msg292215
2017-04-12 22:14:50cheryl.sabellasetmessages: + msg291575
2017-04-12 12:49:34cheryl.sabellacreate