Lesser known parts of Python standard library

Collections & data structures

• collections highlighted as especially valuable: defaultdict, OrderedDict, namedtuple, deque, ChainMap, and Counter.
• defaultdict praised for nested-structure accumulation without manual initialization.
• ChainMap noted as underrated: layered configs, combined namespaces, structured logging, and storage abstraction.
• frozenset cited for hashable/immutable set semantics, especially for combination-based indexing where order shouldn’t matter.
• array and struct mentioned for memory‑efficient homogeneous data and binary packing/unpacking; arrays are often slower than lists but use far less memory.

Itertools, functools & functional style

• itertools (e.g., takewhile, cycle, chain, groupby) and functools (lru_cache, partial, wraps) broadly praised as “superpowers.”
• Some complain Python’s syntax and weak typing support make complex iterator pipelines unwieldy, leading them to other languages (e.g., Kotlin) or to converting back to lists.
• more_itertools, toolz, and the itertools “recipes” are mentioned as valuable complements.

Dict ordering & OrderedDict debate

• Extensive debate: since 3.7, dict’s insertion order is guaranteed by the language spec (3.6 had it as a CPython detail).
• Many argue OrderedDict is mostly obsolete except for extra methods (move_to_end, queue/stack patterns, order-sensitive equality).
• Others still use it for older Python (2.x/3.6), readability (“order matters here”), or to avoid relying on version-specific guarantees.
• Some warn that treating pre‑3.7 dicts as ordered has caused rare, hard-to-debug bugs.

Dataclasses, namedtuple & validation libs

• Several people have moved from namedtuple to frozen dataclasses; others still like namedtuple for light weight and helpers like _make()/_asdict().
• Example patterns: mapping DB rows into named tuples or dataclasses; using sqlite3.Row as an alternative.
• attrs/cattrs preferred by some over Pydantic, which is seen as ergonomically heavy.
• Pydantic raised as a “next step” but met with pushback over friction.

Other lesser-known stdlib features

• graphlib.TopologicalSorter appreciated but criticized for a rigid interface; some say topo sort is easy enough to hand-roll.
• MappingProxyType praised for read‑only live dict views.
• statistics liked for convenience but acknowledged as ~10x slower than NumPy.
• decimal and fractions.Fraction mentioned; relation to IEEE decimal arithmetic marked as unclear.
• Other callouts: contextlib.ExitStack (flattening context managers), dis vs ast for inspection, graphlib, Fraction syntax sugar, zipapp.

CLIs, built-ins & “Easter eggs”

• Handy CLI modules: python -m http.server, -m json.tool, -m zipfile, plus pydoc -p 0 and in‑REPL help().
• Lightweight HTTP server in stdlib considered “good enough” for simple cases; some wish for a Flask‑like server and a requests-style client in stdlib.
• Humorous/educational imports: antigravity, from __future__ import braces, import this.

LLMs vs batteries-included

• One line of discussion suggests LLMs lower the need for tiny helper functions in stdlib or third‑party libs: developers can generate small utilities on demand.
• Others argue this is a step backward versus using well‑tested, idiomatic stdlib tools; homegrown/LLM‑generated code risks subtle bugs and inconsistency.
• There’s recognition that past debates about adding utilities vs. relying on libraries (e.g., more_itertools) might be softened by cheap code generation, but concerns remain about readability and maintainability.