iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
pep-0008.txt
View File

@ -474,22 +474,21 @@ Naming Conventions
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.
The story is largely the same as with functions: in general, use
lowercase with words separated by underscores as necessary to improve
readability.
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 one leading underscore only for internal methods and instance
variables which are not intended to be part of the class's public
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
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.
Use two leading underscores to denote class-private names. Python
"mangles" these names with the class name: if class Foo has an
attribute named __a, it cannot be accessed by Foo.__a. (An insistent
user could still gain access by calling Foo._Foo__a.) Generally,
double leading underscores should be used only to avoid name conflicts
with attributes in classes designed to be subclassed.
Designing for inheritance