[Python-Dev] PEP 8 updates/clarifications

[Guido van Rossum]

On 12/14/05, François Pinard <pinard at iro.umontreal.ca> wrote:
> I would like that PEP 0008 add some cement around this idea that common
> English words, properly spelled, which are likely to be user variable
> names, be avoided whenever reasonable.

I don't think that's a reasonable rule. There are too many English
words and the rule as formulated is too vague. Also, module/package
names can only conflict with *global* user variable names.

> * Within "Code lay-out", "Blank Lines", we read:
>
>     Separate top-level function and class definitions with two blank lines.
>
> In a running English text (like in this message!), it might make sense,
> but after tried for a long while both a single line and two lines
> between top-level elements in Python programs, I did not see that two
> lines gives so much more legibility to be worth a prescription.  One
> white line is enough in my opinion, and I wonder if "with two blank
> lines" could not be replaced by "at least one blank line".

Here I agree, especially bewteen top-level functions. You *might* want
to separate classes with two blank lines if the methods within them
are separated by single blank lines, but even there it's probably
overkill.
>
> * Within "Programming Recommendations", writers are suggested to prefer
> str methods of the string module, as well as a few others more recent
> additions (recent in the history of Python).  I wonder if this would not
> be a good place to suggest more of such.  These come to mind:
>
>     - Replacing "apply(func, args)" with "func(*args)".
>     - Replacing "for line in file.readlines():" with "for line in file:".
>     - Replacing "for key in dict.keys():" with "for key in dict:".
>     - Replacing "if has_key(dict, key):" with "if key in dict:".
>
> and there might be others.

+; however see below.

> Deprecated functions could be listed, too.

I think that's more proper for a separate PEP -- the style guide
shouldn't have to be updated each time something else is deprecated.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)