PEP 8 and extraneous whitespace

[OKB (not okblacke)]

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:
> 
> http://thedailywtf.com/Articles/The-Shapes.aspx
> 
> 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
> lines:
> 
> -----
> "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"
> "-f\tFooify\n"
> "-b\tBarify\n"
> "\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 
indentation.

    	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)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown