Make the section on consistency a separate section, as in the

original.  Close an unmatched parenthesis at the very end.
This commit is contained in:
Guido van Rossum 2001-07-05 20:38:11 +00:00
parent 786551c3db
commit 8bee56c3bf
1 changed files with 18 additions and 6 deletions

View File

@ -16,8 +16,23 @@ Introduction
Please see the companion informational PEP describing style
guidelines for the C code in the C implementation of Python[1].
Note, rules are there to be broken. Two good reasons to break a
particular rule:
This document was adapted from Guido's original Python Style
Guide essay[2]. This PEP inherits that essay's incompleteness.
A Foolish Consistency is the Hobgoblin of Little Minds
A style guide is about consistency. Consistency with this style
guide is important. Consistency within a project is more
important. Consistency within one module or function is most
important.
But most importantly: know when to be inconsistent -- sometimes
the style guide just doesn't apply. When in doubt, use your best
judgement. Look at other examples and decide what looks best. And
don't hesitate to ask!
Two good reasons to break a particular rule:
(1) When applying the rule would make the code less readable, even
for someone who is used to reading code that follows the rules.
@ -26,9 +41,6 @@ Introduction
(maybe for historic reasons) -- although this is also an
opportunity to clean up someone else's mess (in true XP style).
This document was adapted from Guido's original Python Style
Guide essay[2]. This PEP inherits that essay's incompleteness.
Code lay-out
@ -377,7 +389,7 @@ Naming Conventions
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.
could gain access nevertheless, e.g. via the __dict__ attribute.)
References