[Python-Dev] PEP 8 updates/clarifications (original) (raw)
Guido van Rossum guido at python.org
Thu Dec 15 03:42:25 CET 2005
- Previous message: [Python-Dev] PEP 8 updates/clarifications
- Next message: [Python-Dev] PEP 8 updates/clarifications
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 haskey(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/)
- Previous message: [Python-Dev] PEP 8 updates/clarifications
- Next message: [Python-Dev] PEP 8 updates/clarifications
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]