Guido sees the light: PEP 8 updated
Tim Chase
python.list at tim.thechases.com
Tue Apr 19 09:31:01 EDT 2016
On 2016-04-19 14:47, Marko Rauhamaa wrote:
> We need a PEP to distinguish also between:
> - typefaces (Times New Roman vs Garamond)
> - weights (bold vs thin)
> - serifs (with or without)
> - sizes (8pt vs 11pt)
> - colors (goldenrod vs maroon)
Like HTML & CSS, the goal should be to separate the code (HTML) from
its presentation (how it appears in your editor).
It's why I've taken to using formulaic indenting (one or two
indents depending on whether the continued line starts an
indented block) rather than trying to align with something in a prior
line. It drives me nuts when I globally change the spelling of
something (and thus the length of some variable name) and then feel
obligated to re-indent my continuations to get them to line back up
with some arbitrary paren. Compare
def do_something(param1,
param2,
param3,
):
implementation()
with just using
def do_something(param1,
param2,
param3,
):
implementation()
(or, if you want your params to line up
def do_something(
param1,
param2,
param3,
):
implementation()
which is usually how I end up splitting them)
When "do_something" changes to "frobify", I don't feel the need to go
play with indentation with my scheme.
Likewise, I detest aligning comments and almost always prefer to put
them in a neighboring line if there's continuation:
foo = bar * 3 + 2 # we have 3 bars
# plus one for margin on either side
changing the length of the code portion (say, s/bar/inner_width/) will
require re-indenting (and possibly re-flowing) the comments.
It's even worse if the comment flows to an unrelated line
foo = bar * 3 + 2 # we have 3 bars
result = apply(bar) # plus one for margin on either side
Now, if either line of *code* changes, it requires rejiggering the
comment indentation.
If the comment gets moved above, it's no longer an issue:
# we have 3 bars plus one for margin on either side
foo = bar * 3 + 2
result = apply(bar)
I strongly advocate from keeping the content (the code and its AST)
separate from its presentation.
-tkc
More information about the Python-list
mailing list