"Built-in Types" page is too long

[barneygale]

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

[ncoghlan]

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).

[ncoghlan]

The 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
  • __iter__()
  • __iter__()
  • __next__()
  • Generator Types
• Sequence Types — list, tuple, range
  • Common Sequence Operations
  • Immutable Sequence Types
  • Mutable Sequence Types
  • Lists
  • Tuples
  • Ranges
• Text Sequence Type — str
  • str
  • String Methods
  • Move Format String Syntax here
  • printf-style String Formatting
• 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
  • set
  • frozenset
• Mapping Types — dict
  • dict
  • Dictionary view objects
• Context Manager Types
  • __enter__()
  • __exit__()
• Type Annotation Types — Generic Alias, Union
  • Generic Alias Type
  • Union Type
• Other Built-in Types
  • Modules
  • Classes and Class Instances
  • Functions
  • Methods
  • Code Objects
  • Type Objects
  • The Null Object
  • The Ellipsis Object
  • The NotImplemented Object
  • Internal Objects
  • Special Attributes

[JelleZijlstra]

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 set works, 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 types module are best documented in the types module docs, so I would move discussion of code objects etc. into types.