Patch 919256

Clarify and standardize the format for names of modules, functions,
methods, and instance variables.

Consistent, I hope, with discussion on python-dev

http://mail.python.org/pipermail/python-dev/2004-March/043257.html

http://mail.python.org/pipermail/python-dev/2004-March/043259.html

pep-0008.txt

@@ -424,35 +424,26 @@ Naming Conventions
 
     Module Names
 
-      Module names can be either CapWords or lowercase.  There is no
-      unambiguous convention to decide which to use.  Modules that
-      export a single class (or a number of closely related classes,
-      plus some additional support) are often named in CapWords, with
-      the module name being the same as the class name (e.g. the
-      standard StringIO module).  Modules that export a bunch of
-      functions are usually named in all lowercase.
+      Modules should have short, lowercase names, without underscores.
 
-      Since module names are mapped to file names, and some file
-      systems are case insensitive and truncate long names, it is
-      important that module names be chosen to be fairly short and not
-      in conflict with other module names that only differ in the case
-      -- this won't be a problem on Unix, but it may be a problem when
-      the code is transported to Mac or Windows.
+      Since module names are mapped to file names, and some file systems
+      are case insensitive and truncate long names, it is important that
+      module names be chosen to be fairly short -- this won't be a
+      problem on Unix, but it may be a problem when the code is
+      transported to Mac or Windows.
 
-      There is an emerging convention that when an extension module
-      written in C or C++ has an accompanying Python module that
-      provides a higher level (e.g. more object oriented) interface,
-      the Python module's name CapWords, while the C/C++ module is
-      named in all lowercase and has a leading underscore
+      When an extension module written in C or C++ has an accompanying
+      Python module that provides a higher level (e.g. more object
+      oriented) interface, the C/C++ module has a leading underscore
       (e.g. _socket).
 
-      Python packages generally have a short all lowercase name.
+      Python packages should have short, all-lowercase names, without
+      underscores.
 
     Class Names
 
-      Almost without exception, class names use the CapWords
-      convention.  Classes for internal use have a leading underscore
-      in addition.
+      Almost without exception, class names use the CapWords convention.
+      Classes for internal use have a leading underscore in addition.
 
     Exception Names
 
@@ -464,22 +455,20 @@ Naming Conventions
 
     Function Names
 
-      Plain functions exported by a module can either use the CapWords
-      style or lowercase (or lower_case_with_underscores).  There is
-      no strong preference, but it seems that the CapWords style is
-      used for functions that provide major functionality
-      (e.g. nstools.WorldOpen()), while lowercase is used more for
-      "utility" functions (e.g. pathhack.kos_root()).
+      Function names should be lowercase, possibly with underscores to
+      improve readability.  mixedCase is allowed only in contexts where
+      that's already the prevailing style (e.g. threading.py), to retain
+      backwards compatibility.
 
     Global Variable Names
 
       (Let's hope that these variables are meant for use inside one
       module only.)  The conventions are about the same as those for
-      exported functions.  Modules that are designed for use via "from
-      M import *" should prefix their globals (and internal functions
-      and classes) with an underscore to prevent exporting them.
+      functions.  Modules that are designed for use via "from M import *"
+      should prefix their globals (and internal functions and classes)
+      with an underscore to prevent exporting them.
 
-    Method Names
+    Method Names and Instance Variables
 
       The story is largely the same as for functions.  Use lowercase
       for methods accessed by other classes or functions that are part