Clarifications resulting from further discussion with Barry Warsaw.

This commit is contained in:
Kurt B. Kaiser 2004-03-30 01:12:22 +00:00
parent e13d881fb8
commit 9c67b23e5a
1 changed files with 13 additions and 14 deletions

View File

@ -474,22 +474,21 @@ Naming Conventions
Method Names and Instance Variables Method Names and Instance Variables
The story is largely the same as for functions; in general use lowercase The story is largely the same as with functions: in general, use
with words separated by underscores to improve readability. Do not use lowercase with words separated by underscores as necessary to improve
a leading underscore for methods accessed by other classes or functions readability.
that are part of the implementation of an object type.
Use one leading underscore for "internal" methods and instance variables Use one leading underscore only for internal methods and instance
when there is no chance of a conflict with subclass or superclass variables which are not intended to be part of the class's public
attributes or when a subclass might actually need access to them. interface. Python does not enforce this; it is up to programmers to
respect the convention.
Use two leading underscores (class-private names, enforced by Python Use two leading underscores to denote class-private names. Python
1.4) in those cases where it is important that only the current class "mangles" these names with the class name: if class Foo has an
accesses an attribute. Realize that Python contains enough loopholes so attribute named __a, it cannot be accessed by Foo.__a. (An insistent
that an insistent user could gain access nevertheless, e.g. via the user could still gain access by calling Foo._Foo__a.) Generally,
__dict__ attribute. Generally, double leading underscores should be double leading underscores should be used only to avoid name conflicts
used only to avoid name conflicts with attributes in classes designed to with attributes in classes designed to be subclassed.
be subclassed.
Designing for inheritance Designing for inheritance