A few more minor updates for the Naming Conventions section:

- recommend that all new libraries use the standards, but point out that
  internal consistency with existing standards is more important.

- Use b and B instead of x and X (it's hard to distinguish the case of X in
  some fonts)

- StudlyCaps is another name for CapWords

- Re-order list so Function Names are followed by Method Names.  Also, added a
  few blank lines in the Method Names section, and described how underscores
  should separate words for readability.

- Added that double leading underscore is usually only necessary to resolve
  name conflicts in subclasses.

pep-0008.txt

@@ -342,9 +342,12 @@ Version Bookkeeping
 
 Naming Conventions
 
-    The naming conventions of Python's library are a bit of a mess, so
-    we'll never get this completely consistent -- nevertheless, here
-    are some guidelines.
+    The naming conventions of Python's library are a bit of a mess, so we'll
+    never get this completely consistent -- nevertheless, here are the
+    currently recommended naming standards.  New modules and packages
+    (including 3rd party frameworks) should be written to these standards, but
+    where an existing library has a different style, internal consistency is
+    preferred.
 
   Descriptive: Naming Styles
 
@@ -354,9 +357,9 @@ Naming Conventions
 
     The following naming styles are commonly distinguished:
 
-    - x (single lowercase letter)
+    - b (single lowercase letter)
 
-    - X (single uppercase letter)
+    - B (single uppercase letter)
 
     - lowercase
 
@@ -367,7 +370,8 @@ Naming Conventions
     - UPPER_CASE_WITH_UNDERSCORES
 
     - CapitalizedWords (or CapWords, or CamelCase -- so named because
-      of the bumpy look of its letters[4])
+      of the bumpy look of its letters[4]).  This is also sometimes known as
+      StudlyCaps.
 
     - mixedCase (differs from CapitalizedWords by initial lowercase
       character!)
@@ -453,13 +457,6 @@ Naming Conventions
       while Python modules generally use "Error" (e.g. xdrlib.Error).
       The trend seems to be toward CapWords exception names.
 
-    Function Names
-
-      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
@@ -468,19 +465,31 @@ Naming Conventions
       should prefix their globals (and internal functions and classes)
       with an underscore to prevent exporting them.
 
+    Function Names
+
+      Function names should be lowercase, possibly with words separated by
+      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.
+
     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
-      of the implementation of an object type.  Use one leading
-      underscore for "internal" methods and instance variables when
-      there is no chance of a conflict with subclass or superclass
-      attributes or when a subclass might actually need access to
-      them.  Use two leading underscores (class-private names,
-      enforced by Python 1.4) in those cases where it is important
-      that only the current class accesses an attribute.  (But realize
-      that Python contains enough loopholes so that an insistent user
-      could gain access nevertheless, e.g. via the __dict__ attribute.)
+      The story is largely the same as for functions; in general use lowercase
+      with words separated by underscores to improve readability.  Do not use
+      a leading underscore for methods accessed by other classes or functions
+      that are part of the implementation of an object type.
+
+      Use one leading underscore for "internal" methods and instance variables
+      when there is no chance of a conflict with subclass or superclass
+      attributes or when a subclass might actually need access to them.
+
+      Use two leading underscores (class-private names, enforced by Python
+      1.4) in those cases where it is important that only the current class
+      accesses an attribute.  Realize that Python contains enough loopholes so
+      that an insistent user could gain access nevertheless, e.g. via the
+      __dict__ attribute.  Generally, double leading underscores should be
+      used only to avoid name conflicts with attributes in classes designed to
+      be subclassed.
 
     Designing for inheritance