# PEP 842 postmortem: how do we protect the standard library?

**URL:** <https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575>\
**Category:** Core Development\
**Created:** [August 15, 2026, 6:56pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575 "2026-08-15T18:56:54Z")\
**Posts on this page:** 16\
**Page:** 3

<div class="post-metadata">

**Author:** ![ZeroIntensity](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zerointensity/32/10639_2.png) [@ZeroIntensity](https://discuss.python.org/u/ZeroIntensity)\
**Post date:** [August 18, 2026, 12:08pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/41 "2026-08-18T12:08:21Z")

</div>

Maybe a good start, but we currently document some things that are supposed to be “internal” – though perhaps those should just be promoted to public?

---

<div class="post-metadata">

**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\
**Post date:** [August 18, 2026, 12:10pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/42 "2026-08-18T12:10:14Z")

</div>

Or the documentation clarified.

This was my point about the amount of effort required to actually review the existing docs and fix it, rather than trying to invent a new mechanism that would _also_ require reviewing everything but wouldn’t necessarily fix the docs.

---

<div class="post-metadata">

**Author:** ![barry](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/barry/32/42_2.png) [@barry](https://discuss.python.org/u/barry)\
**Post date:** [August 18, 2026, 2:45pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/43 "2026-08-18T14:45:13Z")

</div>

> [@mikeshardmind](#):
>
> user won’t read docs

[Warsaw’s Fourth Law](https://barry.warsaw.us/software/laws)

---

<div class="post-metadata">

**Author:** ![danielhollas](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/danielhollas/32/8233_2.png) [@danielhollas](https://discuss.python.org/u/danielhollas)\
**Post date:** [August 21, 2026, 4:34pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/44 "2026-08-21T16:34:20Z")

</div>

Possibly relevant to this discussion; PyREPL’s tab completion currently does not respect the ` __all__ ` attributes. Should it?

> <https://github.com/python/cpython/issues/149167>
>
> \# Feature or enhancement
> 
> \### Proposal:
> 
> 
> When using autocomplete in the REPL, \`…from x import \<tab\>\` will show all non-underscore prefixed members. This is a \`dir-like\` behavior that is useful to inspect and understand what can be imported. 
> 
> However, this mechanism isn't filtering on \`\_\_all\_\_\` of the module and can yield a long list of non-useful candidates to autocomplete. Two examples shown below, \`pathlib\` and \`collections.abc\`.
> 
> The feature request is that when a user enters \`from x import \<tab\>\` only the candidates defined in \`\_\_all\_\_\` are listed. 
> 
> \<img width="1280" height="920" alt="Image" src="https://github.com/user-attachments/assets/3465f558-db78-413a-9732-05006d1c6c16" /\>
> 
> \<img width="1280" height="920" alt="Image" src="https://github.com/user-attachments/assets/d389fe97-e303-4e68-be25-5a4e0b532df5" /\>
> 
> 
> \### Has this already been discussed elsewhere?
> 
> No response given
> 
> \### Links to previous discussion of this feature:
> 
> \_No response\_
> 
> 
> \### Linked PRs
> \* gh-156146

---

<div class="post-metadata">

**Author:** ![Jeyekomon](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jeyekomon/32/37480_2.png) [@Jeyekomon](https://discuss.python.org/u/Jeyekomon)\
**Post date:** [September 15, 2026, 9:45am UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/45 "2026-09-15T09:45:28Z")

</div>

Python is built around freedom. If I want to access or modify `shutil._HAS_FCOPYFILE`, I should have the full right to do so. Slapping my fingers with `ExportError` when I try to access a private attribute is plain unacceptable and against the spirit of Python. We’re all consenting adults here and we deeply care about core principles. Also that single leading underscore clearly and immediately communicates that I am doing something wrong and that I should be prepared to bear the consequences.

---

<div class="post-metadata">

**Author:** ![gdchinacat](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/gdchinacat/32/37254_2.png) [@gdchinacat](https://discuss.python.org/u/gdchinacat)\
**Post date:** [September 15, 2026, 7:23pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/46 "2026-09-15T19:23:00Z")

</div>

> [@Jeyekomon](#):
>
> We’re all consenting adults here and we deeply care about core principles.

Consent does not mean I’ll “be prepared to bear the consequences”, it means abiding by what the other party has said they are OK with. The motivation in this thread is to provide a mechanism where library authors are able to prevent violations of their consent. It is intended to improve the “consenting adults” ethos by preventing non-consensual uses.

---

<div class="post-metadata">

**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\
**Post date:** [September 15, 2026, 8:13pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/47 "2026-09-15T20:13:20Z")

</div>

We clearly need a new term besides “consenting adults”, since culturally that phrase has come to mean something far more specific, and not what it was always meant to mean in the context it was written for Python.

How about “adults who don’t blame other people for problems we can solve ourselves”? (There may be a shorter version, but the risk of misinterpretation suggests we should be more wordy for the sake of making sure everyone understands what we currently, and have always, meant.)

---

<div class="post-metadata">

**Author:** ![aroberge](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/aroberge/32/6200_2.png) [@aroberge](https://discuss.python.org/u/aroberge)\
**Post date:** [September 15, 2026, 8:34pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/48 "2026-09-15T20:34:56Z")

</div>

> [@steve.dower](#):
>
> How about “adults who don’t blame other people for problems we can solve ourselves”?

Good point about the pitfalls associated with “consenting adults”. At the risk of bikeshedding, instead of what you suggest, I would prefer something like “programmers who share code freely”.

---

<div class="post-metadata">

**Author:** ![NeilGirdhar](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/neilgirdhar/32/5776_2.png) [@NeilGirdhar](https://discuss.python.org/u/NeilGirdhar)\
**Post date:** [September 15, 2026, 9:11pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/49 "2026-09-15T21:11:02Z")

</div>

It should be possible to put this much more simply: “Do whatever you want.”

At the end of the day, there’s always going to be a tension between creating guardrails (safety) and not wanting to be constrained by them (freedom). That’s true of public, final, type annotations, and so on. There isn’t some universal principle that tells you where the line should be drawn.

In this case, some people want the ability to create guardrails that prevent access to private names, while others don’t want to give up the freedom to access them.

I think the Zen of Python suggests that Python has historically leaned toward freedom over safety. Quoting the Zen is useful when it helps express that idea, but I don’t think it was ever meant to function as a universal rule.

---

<div class="post-metadata">

**Author:** ![steve.dower](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steve.dower/32/56_2.png) [@steve.dower](https://discuss.python.org/u/steve.dower)\
**Post date:** [September 15, 2026, 9:33pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/50 "2026-09-15T21:33:49Z")

</div>

> [@NeilGirdhar](#):
>
> It should be possible to put this much more simply: “Do whatever you want.”

Except you immediately run into the “What if everyone did this” problem, which you even went ahead and demonstrated.

This is why Python has historically fallen on the side of the _final_ developer getting to choose what they access, rather than the earlier stage developers deciding what the final developer will get to access. It’s the approach that provides the most freedom for the person carrying the most risk, and it doesn’t hit the “what if everyone” problem because there is nobody else after that final developer.

Ultimately, when you’re deciding the rules, either you are the only one who gets freedom or you can allow everyone to have freedom - you can’t choose to let some people have the freedom and others not.

> [@NeilGirdhar](#):
>
> Quoting the Zen is useful when it helps express that idea, but I don’t think it was ever meant to function as a universal rule.

This is true, and easily demonstrated by almost every second statement in the Zen contradicting the one that came right before it.

But pointing this out doesn’t invalidate the principle. It’s much easier to point to the complete lack of a concept of private members for the entire lifespan of Python so far and say “Python avoids letting type developers control whether their users can access the fields” - nobody has to appeal to the Zen when we have such a long, obvious history of preferring it.

---

<div class="post-metadata">

**Author:** ![NeilGirdhar](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/neilgirdhar/32/5776_2.png) [@NeilGirdhar](https://discuss.python.org/u/NeilGirdhar)\
**Post date:** [September 15, 2026, 10:23pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/51 "2026-09-15T22:23:30Z")

</div>

> [@steve.dower](#):
>
> t’s the approach that provides the most freedom for the person carrying the most risk,

Sure, this is the freedom argument. But the safety argument wants to limit that. That’s what hiding or deleting things from the interface does, or annotating variables as final, etc.

I agree that Python has historically been much more free than it is “safe”. I’m not sure that history is any more compelling than the Zen when it comes to making language decisions.

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [September 15, 2026, 10:49pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/52 "2026-09-15T22:49:57Z")

</div>

> [@Jeyekomon](#):
>
> Python is built around freedom. If I want to access or modify `shutil._HAS_FCOPYFILE`, I should have the full right to do so.

That’s not what I meant the spirit of the language to be at all! I don’t know where you got that idea.

Any conclusions drawn from that misunderstanding are not sensible arguments against such a proposal.

And the “consenting adults” metaphor (always an expression used in jest) also implies that if I prefix a name with an underscore, you will refrain from using it.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [September 16, 2026, 6:48am UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/53 "2026-09-16T06:48:25Z")

</div>

> [@guido](#):
>
> And the “consenting adults” metaphor (always an expression used in jest) also implies that if I prefix a name with an underscore, you will refrain from using it.

To me, “trust the user” captures this - trust the user to respect your declared intentions (or at a minimum not to complain to you if they don’t).

Enforcement is a way of expressing your intent, but it implies less trust than just stating your intent. As such, it may be necessary sometimes, but IMO it shouldn’t be the default or preferred option.

---

<div class="post-metadata">

**Author:** ![mikeshardmind](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikeshardmind/32/14381_2.png) [@mikeshardmind](https://discuss.python.org/u/mikeshardmind)\
**Post date:** [September 16, 2026, 1:37pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/54 "2026-09-16T13:37:35Z")

</div>

Agreed with “trust the user”. I think this is why the options I’ve felt “best” about are ones that lean toward clarifying intent and if they came with enforcement, the enforcement is “trivial to opt out of, with knowledge”

---

<div class="post-metadata">

**Author:** ![guido](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/guido/32/21_2.png) [@guido](https://discuss.python.org/u/guido)\
**Post date:** [September 16, 2026, 10:44pm UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/55 "2026-09-16T22:44:55Z")

</div>

My main point is that I don’t trust users claiming their “freedom” should override everything else.

My ideal outcome here is enforcement when the author wants it, with an easy way to opt out for specific cases. (Which is what the hub model already has, but other approaches lack.)

---

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [October 4, 2026, 1:25am UTC](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575/56 "2026-10-04T01:25:45Z")

</div>

> [@mikeshardmind](#):
>
> Agreed with “trust the user”. I think this is why the options I’ve felt “best” about are ones that lean toward clarifying intent and if they came with enforcement, the enforcement is “trivial to opt out of, with knowledge

While it isn’t particularly pithy, I’ve long thought of our “hazardous material warning” style approach to this kind of thing as “we’re not going to stop you, but when it inevitably breaks, you get to keep all the shiny pieces”.

[Previous page](https://discuss.python.org/t/pep-842-postmortem-how-do-we-protect-the-standard-library/108575.md?page=2)
