http://hg.python.org/peps/rev/1a40d4eaa00b changeset: 5242:1a40d4eaa00b user: Barry Warsaw <barry@python.org> date: Fri Nov 01 12:56:37 2013 -0400 summary: Ethan Furman's latest patch for Issue 19331. files: pep-0008.txt | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/pep-0008.txt b/pep-0008.txt --- a/pep-0008.txt +++ b/pep-0008.txt @@ -580,6 +580,12 @@ standards, but where an existing library has a different style, internal consistency is preferred. +Overriding Principle +-------------------- + +Names that are visible to the user as public parts of the API should +follow conventions that reflect usage rather than implementation. + Descriptive: Naming Styles -------------------------- @@ -676,8 +682,14 @@ Class Names ~~~~~~~~~~~ -Almost without exception, class names use the CapWords convention. -Classes for internal use have a leading underscore in addition. +Class names should normally use the CapWords convention. + +The naming convention for functions may be used instead in cases where +the interface is documented and used primarily as a callable. + +Note that there is a separate convention for builtin names: most builtin +names are single words (or two words run together), with the CapWords +convention used only for exception names and builtin constants. Exception Names ~~~~~~~~~~~~~~~ -- Repository URL: http://hg.python.org/peps