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

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.

Since no one has said that this change shouldn't be made, I'll start working on this.

New changeset c6db481 by Nick Coghlan (csabella) in branch 'master':
bpo-30052: Link bytes & bytearray to stdtypes not functions (GH-1271)
c6db481

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.

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?

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.

New PR disabling the output caching and adding a corresponding NEWS entry: #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.

New changeset 1c92c0e by Mariatta in branch '3.6':
bpo-30052: Link bytes & bytearray to stdtypes not functions (GH-1271) (GH-1915)
1c92c0e

Sorry, Mariatta. I didn't realize this was waiting for a backport.

New changeset 7a82f9c by Nick Coghlan in branch 'master':
bpo-30052: Always regenerate cross-references (bpo-1339)
7a82f9c

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.

New changeset 798cfb2 by Mariatta (Nick Coghlan) in branch '3.6':
bpo-30052: Always regenerate cross-references (GH-1339) (GH-1921)
798cfb2

Backport PR looks good so I went ahead and merged it :)
Thanks.

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?

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

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!