RetroSearch Browse

Mon Jul 15 07:16:37 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-July/127307.html

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".

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-July/127307.html below:

[Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores