New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rearrange descriptions of builtin types in the Library reference #57083
Comments
Section 4 of the Standard Library reference currently includes the two following sections (amongst others): 4.6. Sequence Types — str, bytes, bytearray, list, tuple, range This is crazy - memoryview, a fairly niche type, gets its own second tier section on the main table of contents, while str, one of the most important types in Python, is tucked away under the generic "Sequence Type" heading? I propose that these sections be rearranged as: 4.6 Sequence Types - list, tuple, range The Set Types and Mapping Types sections would slide down to sections 4.9 and 4.10 to make room for the two new sections. |
Better titles for the proposed new sections: 4.7 Text Data - str |
I agree on the subdivision, but I think they should still be grouped together somehow, since these all really *do* share some interfaces: __getitem__ (with slicing), __iter__, __len__, at least; arguably __contains__; probably some others (see collections/abc.py). |
Putting the new sections on tier 2 makes a big difference in discoverability, since that's the lowest level the main ToC page shows. Perhaps just including the phrase "Sequence Type" in the new section titles would provide enough logical grouping? Something like: 4.6 Sequence Types - list, tuple, range |
That sounds fine. Or list most of them at tier 2: 4.6 Sequence Types - list, tuple, range, str, bytes and friends Although including range() here feels a bit odd? (It's a much more |
'Sequence Types - list, tuple, str, bytes, etc' *might* work, but I think part of the problem is that str's brevity is actually a downside in this case. I know I missed it when I was scanning the ToC earlier (I wanted to check if the internal Unicode repr for narrow builds was documented at all - it doesn't appear to be). |
How about "list, tuple, text and binary strings" ? |
I believe this is a duplicate of bpo-4966. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: