From the discussion thus far, I get the impression that we can split people who use private APIs into three main groups:
- People who do this truly accidentally—e.g., because their IDE’s autocomplete suggests a private API that sounds like it might do what they’re looking for.
- People who deliberately use a private API and are aware of the risks. (This includes internal use within a package.)
- People who are copy-pasting a code snippet (usually from someone in group 2) to fulfil a specific need, without thinking too much about the code snippet.
For group 1, I think this PEP would indeed be helpful once it’s supported by IDEs.
For group 2, this PEP would not change much; they will continue to do this, e.g., using the del module.__export__ workaround. (Adding a single line of boilerplate to get the expected result right now is still orders of magnitude less friction than posting an issue upstream to ask for a public API and then waiting months to years for this to be accepted, implemented and released; so I don’t think this will be sufficient encouragement to make a practical difference.)
For group 3, I also don’t think that this PEP would change much. The code snippet they copy is now going to be one line longer; but that one del module.__export__ line does not look “scary” enough to be an effective deterrent.[1]
Framed like this, the question to me becomes whether group 1 actually makes up a large fraction of private API usage. If they do, then this PEP could make a significant difference and I would support it. If, however, groups 2 and 3 dominate, then I don’t expect this PEP to make a significant difference and, to me, the small improvement it offers w/r/t group 1 is outweighed by the additional boilerplate and churn it introduces.
