Patch 919256
Clarify and standardize the format for names of modules, functions, methods, and instance variables. Consistent, I hope, with discussion on python-dev http://mail.python.org/pipermail/python-dev/2004-March/043257.html http://mail.python.org/pipermail/python-dev/2004-March/043259.html
This commit is contained in:
parent
862ec109bd
commit
fef61c2a39
53
pep-0008.txt
53
pep-0008.txt
|
@ -424,35 +424,26 @@ Naming Conventions
|
||||||
|
|
||||||
Module Names
|
Module Names
|
||||||
|
|
||||||
Module names can be either CapWords or lowercase. There is no
|
Modules should have short, lowercase names, without underscores.
|
||||||
unambiguous convention to decide which to use. Modules that
|
|
||||||
export a single class (or a number of closely related classes,
|
|
||||||
plus some additional support) are often named in CapWords, with
|
|
||||||
the module name being the same as the class name (e.g. the
|
|
||||||
standard StringIO module). Modules that export a bunch of
|
|
||||||
functions are usually named in all lowercase.
|
|
||||||
|
|
||||||
Since module names are mapped to file names, and some file
|
Since module names are mapped to file names, and some file systems
|
||||||
systems are case insensitive and truncate long names, it is
|
are case insensitive and truncate long names, it is important that
|
||||||
important that module names be chosen to be fairly short and not
|
module names be chosen to be fairly short -- this won't be a
|
||||||
in conflict with other module names that only differ in the case
|
problem on Unix, but it may be a problem when the code is
|
||||||
-- this won't be a problem on Unix, but it may be a problem when
|
transported to Mac or Windows.
|
||||||
the code is transported to Mac or Windows.
|
|
||||||
|
|
||||||
There is an emerging convention that when an extension module
|
When an extension module written in C or C++ has an accompanying
|
||||||
written in C or C++ has an accompanying Python module that
|
Python module that provides a higher level (e.g. more object
|
||||||
provides a higher level (e.g. more object oriented) interface,
|
oriented) interface, the C/C++ module has a leading underscore
|
||||||
the Python module's name CapWords, while the C/C++ module is
|
|
||||||
named in all lowercase and has a leading underscore
|
|
||||||
(e.g. _socket).
|
(e.g. _socket).
|
||||||
|
|
||||||
Python packages generally have a short all lowercase name.
|
Python packages should have short, all-lowercase names, without
|
||||||
|
underscores.
|
||||||
|
|
||||||
Class Names
|
Class Names
|
||||||
|
|
||||||
Almost without exception, class names use the CapWords
|
Almost without exception, class names use the CapWords convention.
|
||||||
convention. Classes for internal use have a leading underscore
|
Classes for internal use have a leading underscore in addition.
|
||||||
in addition.
|
|
||||||
|
|
||||||
Exception Names
|
Exception Names
|
||||||
|
|
||||||
|
@ -464,22 +455,20 @@ Naming Conventions
|
||||||
|
|
||||||
Function Names
|
Function Names
|
||||||
|
|
||||||
Plain functions exported by a module can either use the CapWords
|
Function names should be lowercase, possibly with underscores to
|
||||||
style or lowercase (or lower_case_with_underscores). There is
|
improve readability. mixedCase is allowed only in contexts where
|
||||||
no strong preference, but it seems that the CapWords style is
|
that's already the prevailing style (e.g. threading.py), to retain
|
||||||
used for functions that provide major functionality
|
backwards compatibility.
|
||||||
(e.g. nstools.WorldOpen()), while lowercase is used more for
|
|
||||||
"utility" functions (e.g. pathhack.kos_root()).
|
|
||||||
|
|
||||||
Global Variable Names
|
Global Variable Names
|
||||||
|
|
||||||
(Let's hope that these variables are meant for use inside one
|
(Let's hope that these variables are meant for use inside one
|
||||||
module only.) The conventions are about the same as those for
|
module only.) The conventions are about the same as those for
|
||||||
exported functions. Modules that are designed for use via "from
|
functions. Modules that are designed for use via "from M import *"
|
||||||
M import *" should prefix their globals (and internal functions
|
should prefix their globals (and internal functions and classes)
|
||||||
and classes) with an underscore to prevent exporting them.
|
with an underscore to prevent exporting them.
|
||||||
|
|
||||||
Method Names
|
Method Names and Instance Variables
|
||||||
|
|
||||||
The story is largely the same as for functions. Use lowercase
|
The story is largely the same as for functions. Use lowercase
|
||||||
for methods accessed by other classes or functions that are part
|
for methods accessed by other classes or functions that are part
|
||||||
|
|
Loading…
Reference in New Issue