PEP 8 and extraneous whitespace
OKB (not okblacke)
brenNOSPAMbarn at NObrenSPAMbarn.net
Fri Jul 29 20:45:33 CEST 2011
Chris Angelico wrote:
> On Thu, Jul 28, 2011 at 4:18 PM, OKB (not okblacke)
>> I think exactly the opposite. The source file should re flect
>> the semantic organization of the code, without extraneous concessions
>> to visual display (like "lining things up" with spaces or splitting
>> long lines with hard newlines). The editor should present the code
>> nicely. People already argue for this general mindset when they say
>> that "any good edit will let you set the tab width", etc.
> That mandates that formatting NOT be a part of the language. I could
> take C code and reformat it in various ways with a script, and easily
> guarantee that the script won't affect the code by simply having it
> only ever adjust whitespace. This concept simply won't work in Python.
"Formatting" is too general a term. Obviously "formatting" in
the lay sense is part of any language, since things like commas and
parentheses matter. What Python does that's unusual is pay attention to
INDENTATION, which is a very specific part of formatting involving
whitespace at the beginning of a line. This isn't incompatible with
what I outlined above.
> Personally, I like to be able to format things according to where they
> came from, or other criteria. Take a look at this code, for instance;
> the post has highlighted the difference between 1 and 0, but otherwise
> hasn't changed it:
> Note how the formatting is beautifully consistent. Each line is
> wrapped to a tidy 70 characters, or whatever it is (I haven't
> counted). Each data row, therefore, has the same number of characters
> in it. But is that useful? Would it not be far more useful to wrap
> them each at their image widths? Yes, it might take a bit more
> vertical space, but the source code would *look like the image* and
> that massively helps readability. This is why a source code tidying
> script can't fully grok readability; if a program looks at a sequence
> of strings, how can it know where to break them? All of these
> (hypothetical) examples are single string literals, broken across
> "This is string 1.\0"
> "This is string 2, and it is longer.\0"
> "String 3.\0"
> "This is a long paragraph of"
> "text, which I have wrapped somewhat messily, and"
> "which a good text"
> "tidying program should be able to clean up"
> "for me."
> "Usage: programname [options] [argument]\n"
> "argument should be either '5-minute' or 'course'\n"
> Can you write a script that perfectly handles these sorts of literals?
> Considering that the divider in the first one might not be \0, but
> might be any character or even string of characters, it's not really
> possible for an editor to know where to wrap something; which means
> that it's up to the programmer to make things readable. And that
> demands that the programmer know what he's doing, and that the
> programmer have the power to express what he's doing how he chooses.
> Overly-strict formatting rules/guides remove that power.
I don't think I understand what you're getting at there. What
would you mean "handling" those string literals? I'm just talking about
an editor that displays things in a way that respects semantic
indentation that you put in. I'm not talking about some sort of
"script" that would take your second two examples and make them look
nice. The editor would need to know Python's string literal syntax to
do that. If you want to write things in those ways, okay, but my
preference would be to always write them as one big string literal
(e.g., triple-quoted), and then have the editor strip away shared
So I guess I was a bit unclear when I said "the editor should
present the code nicely". I just mean that the editor should present
the code in a way that reflects the semantic indentation present, thus
relieving users of the need to insert redundant linebreaks and
whitespace to make things "line up". I don't mean that it should try to
"prettify" things in the way you seem to be suggesting.
As an aside, I don't think string literals are a great example case
for these issues. ALL whitespace (not just indentation), and all
of everything else, always matters in string literals, so you do indeed
have to put in explicit whitespace if you want explicit whitespace in
the string. In code, though, explicit whitespace is only needed to
indicate semantically meaningful stuff, so you should only use it for
that, and the editor should insert "visual space" (without actual
whitespace characters in the file) to make things like up at the
semantic indentation levels.
--OKB (not okblacke)
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
More information about the Python-list