Update PEP based on new wording in PEP 8 (allowing the use of underscores in

module names).
This commit is contained in:
Brett Cannon 2007-01-05 20:23:56 +00:00
parent f59bb95222
commit c3867b3154
1 changed files with 20 additions and 25 deletions

View File

@ -197,12 +197,12 @@ their maintenance.
- No longer distributed with Python. - No longer distributed with Python.
Minimal usage Hardly used
------------- ------------
Some modules that are platform-independent have minimal usage. This Some modules that are platform-independent are hardly used. This
can be from how easy it is to implement the functionality from scratch can be from how easy it is to implement the functionality from scratch
or because the audience for the code is small. or because the audience for the code is very small.
* audiodev * audiodev
@ -351,40 +351,35 @@ required naming scheme is *not* listed below.
PEP 8 violations PEP 8 violations
---------------- ----------------
PEP 8 specifies that modules "should have short, lowercase names, PEP 8 specifies that modules "should have short, all-lowercase names"
without underscores" [#pep-0008]_. There is no mention, though, if where "underscores can be used ... if it improves readability"
this rule extends to modules contained within a package. The [#pep-0008]_. The use of underscores is discouraged in package names.
assumption is that underscores are acceptable in module names when
they are contained within a package but that any uppercase letters is
not.
================== ================================================== ================== ==================================================
Current Name Replacement Name Current Name Replacement Name
================== ================================================== ================== ==================================================
_winreg winreg (rename also because module has a public _winreg winreg (rename also because module has a public
interface) interface and thus should not have a leading
BaseHTTPServer basehttpserver underscore)
BaseHTTPServer base_http_server
Carbon carbon Carbon carbon
CGIHTTPServer cgihttpserver CGIHTTPServer cgi_http_server
ColorPicker colorpicker ColorPicker colorpicker
ConfigParser configparser ConfigParser configparser
Cookie cookie Cookie cookie
copy_reg copyreg copy_reg copyreg
DocXMLRPCServer docxmlrpcserver DocXMLRPCServer doc_xmlrpc_server
dummy_threading mockthreading (rename because "mock" makes more
sense than "dummy" and rename already required)
EasyDialogs easydialogs EasyDialogs easydialogs
HTMLParser htmlparser HTMLParser htmlparser
MacOS macos MacOS macos
Nav nav Nav nav
PixMapWrapper pixmapwrapper PixMapWrapper pixmap_wrapper
py_compile pycompile
Queue queue Queue queue
repr reprlib (rename because module name shadows a repr reprlib (rename because module name shadows a
built-in) built-in)
ScrolledText scrolledtext ScrolledText scrolledtext
SimpleHTTPServer simplehttpserver SimpleHTTPServer simple_http_server
SimpleXMLRPCServer simplexmlrpcserver SimpleXMLRPCServer simple_xmlrpc_server
SocketServer socketserver SocketServer socketserver
StringIO stringio StringIO stringio
Tix tix Tix tix
@ -448,8 +443,8 @@ bdb _bdb
cl _cl cl _cl
markupbase _markupbase markupbase _markupbase
opcode _opcode opcode _opcode
dummythread _mockthread (assuming the dummy_thread _dummy_thread (assuming thread
deprecation of 'thread' occurs) is deprecated)
============ =============================== ============ ===============================
@ -526,10 +521,10 @@ for the suggested package (if not already existent) is being proposed.
Have a package for Python implementations of built-in types Have a package for Python implementations of built-in types
instead of putting the User* modules into 'collections'? instead of putting the User* modules into 'collections'?
* mac * Platform-specific
+ Various Mac-specific modules. + All platform-specific modules should be placed in a package
+ Same can be done for other platform-specific code. representing the platform.
* Profiling * Profiling