Repository navigation
"Built-in Types" page is too long #126052
Description
Activity
See #126053 for discussion of the link instability this introduces for deep links that include anchor tags, and potential mitigation strategies (we don't want to have the same discussion in two places).
Reacted by Barney Gale and Tushar SadhwaniThe existing sections in this page would provide a reasonable break down across multiples pages (subsection moves noted in the list). Top level bullet points would be separate pages (retaining the current top level landing page as an overview page, including its navigation table):
- Logical operations
- Truth Value Testing
- Boolean Operations — and, or, not
- Comparisons
- Boolean Type - bool (moved out of Numeric types)
- Numeric Types —
int,float,complex- Bitwise Operations on Integer Types
- Additional Methods on Integer Types
- Additional Methods on Float
- Hashing of numeric types
- Integer string conversion length limitation (moved up from the end of the huge page)
- Iterator Types
- Sequence Types —
list,tuple,range - Text Sequence Type —
str - Binary Sequence Types —
bytes,bytearray,memoryview- Bytes Objects
- Bytearray Objects
- Bytes and Bytearray Operations
- printf-style Bytes Formatting
- Memory Views
- Potentially add a new subsection covering the buffer protocol
- Set Types —
set,frozenset - Mapping Types —
dict - Context Manager Types
- Type Annotation Types — Generic Alias, Union
- Other Built-in Types
Reacted by Barney Gale, Bénédikt Tran, Tushar Sadhwani, adam j hartz and Genki- Logical operations
I would aim towards giving each (major?) builtin type its own page, so it's easy for users to know "if I want to know how
setworks, I can go to docs.python.org/.../set.html".A few sections, e.g. https://docs.python.org/3/library/stdtypes.html#context-manager-types belong in the data model page (which may also be split up). In my mind, stdtypes is part of the library docs and should cover specific concrete types; datamodel is part of the language reference and should cover the magic methods that the Python interpreter itself may implicitly call.
I feel that internal types that are exposed in the
typesmodule are best documented in thetypesmodule docs, so I would move discussion of code objects etc. intotypes.Reacted by Barney Gale, jxu, Tushar Sadhwani, Éric, adam j hartz, Petr Viktorin and arawup
Metadata
Metadata
Assignees
Labels
Projects
- StatusShow more project fieldsTodo
Documentation
The Built-in Types document is very long, and as a result it basically never shows up in search engine results, because 90% of the page is considered irrelevant for any query like "python strings".
I suggest we split it up by top-level topic, e.g. we add a dedicated page for "Text Sequence Type —
str"See also #126053