[Python-checkins] python/nondist/peps pep-0008.txt,1.21,1.22

[bwarsaw at users.sourceforge.net]

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2842

Modified Files:
	pep-0008.txt 
Log Message:
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.


Index: pep-0008.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0008.txt,v
retrieving revision 1.21
retrieving revision 1.22
diff -C2 -d -r1.21 -r1.22
*** pep-0008.txt	20 Mar 2004 06:42:29 -0000	1.21
--- pep-0008.txt	27 Mar 2004 20:14:19 -0000	1.22
***************
*** 343,349 ****
  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.
  
    Descriptive: Naming Styles
--- 343,352 ----
  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 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
***************
*** 355,361 ****
      The following naming styles are commonly distinguished:
  
!     - x (single lowercase letter)
  
!     - X (single uppercase letter)
  
      - lowercase
--- 358,364 ----
      The following naming styles are commonly distinguished:
  
!     - b (single lowercase letter)
  
!     - B (single uppercase letter)
  
      - lowercase
***************
*** 368,372 ****
  
      - CapitalizedWords (or CapWords, or CamelCase -- so named because
!       of the bumpy look of its letters[4])
  
      - mixedCase (differs from CapitalizedWords by initial lowercase
--- 371,376 ----
  
      - CapitalizedWords (or CapWords, or CamelCase -- so named because
!       of the bumpy look of its letters[4]).  This is also sometimes known as
!       StudlyCaps.
  
      - mixedCase (differs from CapitalizedWords by initial lowercase
***************
*** 454,464 ****
        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
  
--- 458,461 ----
***************
*** 469,485 ****
        with an underscore to prevent exporting them.
  
      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.)
  
      Designing for inheritance
--- 466,494 ----
        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; 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