PEP 8 and extraneous whitespace

OKB (not okblacke) brenNOSPAMbarn at NObrenSPAMbarn.net
Sun Jul 31 03:23:24 CEST 2011


Chris Angelico wrote:

> On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
> Suppose you want to have a lengthy piece of text embedded in your
> source code, which you will then pass to a GUI widget for display.
> You want the widget to handle word wrap, so you don't want internal
> line breaks getting in the way, but you want the source code to be
> wrapped. What's the best way to do this? I've never been a fan of
> string literals needing run-time adjustments (like stripping
> indentation from triple-quoted strings - it usually depends on the
> indent on the second line, and what if you want that second line to
> be differently indented from the others?), so to my mind the
> cleanest way would be abuttal: 
> 
>     "Lorem ipsum dolor sit amet, consectetur "
>     "adipiscing elit. Fusce fermentum posuere "
>     "mi eget molestie. Nulla facilisi. Curabitur "
>     "et ultrices massa."
> 
> The code's indented four spaces, but I don't have to strip them
> from the string. (Depending on context, I might need to put parens
> around that to force it to be parsed as a single string. Small
> potatoes.) 

    	Yeah, what I'm suggesting as the cleanest way is to simply make it 
all one long string literal, which is wrapped by the editor to the 
proper indentation point.  I can't show this in a newgroup post, but 
it'd be like:

def somefunc():
    	if someCondition():
    	    	"Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
Fusce fermentum posuere mi eget molestie. Nulla facilisi. Curabitur et 
ultrices massa."

. . . except that the wrapped lines of the lorem ipsum would all line up 
at the same level as the open quote.  This is clean because you get to 
type it exactly as you wanted it.  You don't need to include extraneous 
whitespice to get it to line up or wrap in your editor, and you also 
don't need to choose the wrap points to put in extra quotes, as in your 
example.  The irritating thing about doing it your way is that if you 
later change the text and it rewraps, you have to move your quote marks.
 
>   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. 
> 
> Interesting concept. This suggests that your source file does not
> actually have the indentation, but the display does. This is an
> interesting way of dealing with triple-quoted strings.
> 
>     foo = """This is line 1.
> This is line 2.
> Line 3."""
>     print(foo)
> 
> If that displayed indented, maybe with a faint vertical line
> showing the string's left margin, that would greatly improve
> readability. Any editor that doesn't support this feature would
> simply see it flush left, slightly ugly but workable. Very nice
> idea... but I don't feel like implementing it. :)

    	Right, that's the idea, although actually I don't have an editor 
that goes quite that far.  I use EditPadPro (and previously used 
TextPad), which support this, but only for wrapping single lines of text 
(i.e., without hitting enter).  If you insert a hard linebreak (e.g., to 
separate paragraphs), then explicit indentation is inserted in the 
string.  My usual solution is to insert a hard linebreak right at the 
beginning, so at least all the text is indented by the same amount.  
This does involve inserting extraneous whitespace, but in the least 
obstrusive way possible.

    	The editors have to insert real whitespace on linebreak because you 
need that indentation if you're linebreaking between lines of code.  It 
would be nice if they had Python-aware syntax fiddling that noticed that 
you were hitting Enter inside a triple-quoted string, and suppressed the 
whitespace characters in that situation, but the editors I use don't 
currently do that.


-- 
--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



More information about the Python-list mailing list