Nick Coghlan writes:
Of course private modules are sane. I never suggested "no new private modules at all". But putting them in the same namespace as public modules is not, just to save a leading underscore in the file name.
It's not to save a leading underscore - it's to avoid renaming existing packages like pip and idlelib.
"existing" is not a subset of "new." Am I missing something?<wink/> What Steven is suggesting is that there are two kinds of private package in the stdlib: those that can conveniently be given names that indicate that they are private (generally, "new" packages), and those that can't ("existing" packages). For the latter IIRC he suggested adding a line at the top of the module documentation "This module is *private*, and you cannot depend on API compatibility with future or past releases of this module. The public API is in ... [alternatively, There is no public API]." I really don't see how one can object to this suggestion, given an appropriate definition of "convenient enough to get a _name".