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". _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com