May 26, 2026
Private parts, public meltdown
Opaque Types in Python
Python tries to hide its messy guts, and the comments instantly turn feral
TLDR: The article suggests a way for Python libraries to keep complicated settings hidden while still letting people use them safely. Commenters immediately split into camps: some said it’s clever, others said it fights Python’s whole culture, and one side quest about camelCase nearly upstaged everything.
A fresh Python programming idea about keeping a library’s inner settings hidden from users somehow turned into a full-blown comments-section cage match. The article’s basic pitch is simple: if you’re building a tool with lots of complicated options — like shipping speed, signatures, tracking, and all the other chaos behind sending a package — you may want users to only choose from a few safe buttons while the messy details stay out of sight. The proposed trick uses Python’s type tools to create a public label for an object while the real data lives in a more private structure.
And wow, the community had feelings. One camp basically yelled, “This is not how Python is supposed to work,” with jnwatson delivering the spiciest philosophy lesson of the bunch: Python isn’t about locking things down; it’s about adults behaving like adults. Another crowd was less offended in principle and more exhausted in practice, saying the pattern makes testing awkward and coworker comprehension worse. One commenter said they tried something similar and ditched it because it became too confusing once real-life code got involved.
Then came the style police. A drive-by comment roasted the article’s camelCase function names so hard it almost stole the whole thread. And just when things couldn’t get messier, someone invoked Java as the language that did this better, which is basically the tech-comment equivalent of throwing a chair. In other words: the article was about hiding complexity, but the real entertainment was watching programmers argue over whether Python should hide anything at all.
Key Points
- •The article focuses on Python library design for configuration objects whose public API should remain minimal while internal structure evolves.
- •It uses a shipping-library example where `ShippingOptions` is required by APIs such as `shipPackage` and `estimateShippingCost`.
- •The article argues that exposing a regular Python class or dataclass makes the constructor inherently public, which weakens opacity even if attributes are private.
- •It identifies the opaque data type pattern as the preferred design approach and compares it to common usage in C.
- •The proposed Python implementation uses a public `NewType`, a private backing class, and public constructor functions to create stable typed options objects.