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