Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10052 > unrolled thread

Re: PEP 8 and extraneous whitespace

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: PEP 8 and extraneous whitespace Terry Reedy <tjreedy@udel.edu> - 2011-07-21 18:45 -0400
    Re: PEP 8 and extraneous whitespace Roy Smith <roy@panix.com> - 2011-07-21 21:12 -0400
      Re: PEP 8 and extraneous whitespace Ed Leafe <ed@leafe.com> - 2011-07-21 22:11 -0500
      Re: PEP 8 and extraneous whitespace Ethan Furman <ethan@stoneleaf.us> - 2011-07-25 15:05 -0700
      Re: PEP 8 and extraneous whitespace Thomas Jollans <t@jollybox.de> - 2011-07-26 01:26 +0200
        Re: PEP 8 and extraneous whitespace AlienBaby <matt.j.warren@gmail.com> - 2011-07-26 05:46 -0700
          Re: PEP 8 and extraneous whitespace Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-07-27 10:49 +1000
    Re: PEP 8 and extraneous whitespace Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-07-22 10:11 +0200
      Re: PEP 8 and extraneous whitespace Thomas Jollans <t@jollybox.de> - 2011-07-22 12:23 +0200
      Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 12:59 +0000
        Re: PEP 8 and extraneous whitespace Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-22 12:13 -0600
          Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 19:05 +0000
            Re: PEP 8 and extraneous whitespace John Gordon <gordon@panix.com> - 2011-07-22 19:13 +0000
              Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-22 19:15 +0000
              Re: PEP 8 and extraneous whitespace Brandon Harris <brandon.harris@reelfx.com> - 2011-07-22 14:53 -0500
              Re: PEP 8 and extraneous whitespace Chris Rebert <clp2@rebertia.com> - 2011-07-22 13:56 -0700
                Re: PEP 8 and extraneous whitespace Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-07-28 01:24 +0200
                  Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-28 06:18 +0000
                    Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-29 20:25 +1000
                      Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-29 18:45 +0000
                        Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-30 07:18 +1000
                          Re: PEP 8 and extraneous whitespace "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-07-31 01:23 +0000
                            Re: PEP 8 and extraneous whitespace Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-07-31 18:10 +1200
                            Re: PEP 8 and extraneous whitespace Ben Finney <ben+python@benfinney.id.au> - 2011-07-31 17:56 +1000
                    Re: PEP 8 and extraneous whitespace Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2011-08-01 17:16 +0200
              Re: PEP 8 and extraneous whitespace Corey Richardson <kb1pkl@aim.com> - 2011-07-22 17:17 -0400
              Re: PEP 8 and extraneous whitespace Michael Brown <Michael@invalid.invalid> - 2011-07-24 13:07 +0000
                Re: PEP 8 and extraneous whitespace Zero Piraeus <schesis@gmail.com> - 2011-07-24 11:08 -0400
                  Re: PEP 8 and extraneous whitespace Ben Finney <ben+python@benfinney.id.au> - 2011-07-25 07:37 +1000
                    Re: PEP 8 and extraneous whitespace Neil Cerutti <neilc@norwich.edu> - 2011-07-25 11:37 +0000
      Re: PEP 8 and extraneous whitespace Michiel Overtoom <motoom@xs4all.nl> - 2011-07-22 19:05 +0200
        Re: PEP 8 and extraneous whitespace rusi <rustompmody@gmail.com> - 2011-07-22 10:43 -0700
          Re: PEP 8 and extraneous whitespace Ian Kelly <ian.g.kelly@gmail.com> - 2011-07-22 12:14 -0600
      Re: PEP 8 and extraneous whitespace Chris Angelico <rosuav@gmail.com> - 2011-07-23 03:27 +1000

Page 2 of 2 — ← Prev page 1 [2]

#10548

On Sat, Jul 30, 2011 at 4:45 AM, OKB (not okblacke)
<brenNOSPAMbarn@nobrenspambarn.net> wrote:
> Chris Angelico wrote:
>> 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.

My notion of "formatting" of code is entirely whitespace, but it
includes such things as:

-----
int
declspec(DLLEXPORT) foofunc(
    char *str,
    int num
) {
  printf("%s: %d",
    str,num);
  return 1;
}
-----
int declspec(DLLEXPORT) foofunc(char *str,int num)
{
    printf("%s: %d", str, num);
    return 1;
}
-----

There's a lot of difference between these two, in terms of
readability, but it wouldn't be hard to write a script that could
format the code into your preferred form. It would be far stricter
than I would like to use, but if you have a gigantic mess of code and
you want to start comprehending it (think IOCCC entries), these sorts
of code reformatters are excellent.

>        I don't think I understand what you're getting at there.  What
> would you mean "handling" those string literals?

What I mean is that these string literals are broken across multiple
lines in a way that is meaningful to the human. Doing them with
triple-quoted strings and actual newlines is potentially restrictive;
if you're trying to build up a string of strings (like for a DOS
environment block - each NAME=VALUE pair is followed by a \0 and the
last one by another \0) that could contain newlines, it's better not
to have actual newlines in the string. Of course, there are other
options (make a list of strings, then "\0".join(lst) to make your
final string), but there are times when it's cleanest to simply have a
string literal that consists of multiple lines of source code,
irrespective of newlines in the string.

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

Okay, so you're talking about something a lot narrower than I thought
you were. That's fine then; indentation is much simpler and easier to
manage!

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

That's precisely why abutting is supported for literal concatenation:
>>> "foo" "bar"
'foobar'

>>> ("foo"
"bar")
'foobar'

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

  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. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#10610

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

[toc] | [prev] | [next] | [standalone]

#10616

OKB (not okblacke) wrote:
> You don't need to include extraneous 
> whitespice to get it to line up
   ^^^^^^^^^^

+1 on Python 4 providing whitespice. Should liven things up nicely. :-)

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#10620

"OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> writes:

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

You can have the text indented and wrapped how you like it, then remove
the leading whitespace at run-time with ‘textwrap.dedent’
<URL:http://stackoverflow.com/questions/2504411/proper-indentation-for-python-multiline-strings/2504454#2504454>.

-- 
 \        “Sane people have an appropriate perspective on the relative |
  `\     importance of foodstuffs and human beings. Crazy people can't |
_o__)                 tell the difference.” —Paul Z. Myers, 2010-04-18 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#10671

OKB (not okblacke) wrote:

> Thomas 'PointedEars' Lahn wrote:
>>  Automatic word-wrap, where available, really is not a solution; it
>> is a bad workaround to a problem caused by the original author of
>> the source code that can be easily avoided by them taking more care
>> while coding.
> 
>     I think exactly the opposite.  The source file should reflect 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.

Your approach would require all source code editors to have the same
minimum feature set as you described, with the same settings, which
is unrealistic.  And it would make especially Python code a lot harder
to read (as indentation matters in Python).

Your From header field value is borken.

-- 
PointedEars

Bitte keine Kopien per E-Mail. / Please do not Cc: me.

[toc] | [prev] | [next] | [standalone]

#10156

Excerpts from Chris Rebert's message of Fri Jul 22 16:56:15 -0400 2011:
> On Fri, Jul 22, 2011 at 12:13 PM, John Gordon <gordon@panix.com> wrote:
> > In <98u00kFnfiU1@mid.individual.net> Neil Cerutti <neilc@norwich.edu> writes:
> >
> >> You can fit much more code per unit of horizontal space with a
> >> proportionally spaced font. As a result, that issue, while valid,
> >> is significantly reduced.
> >
> > Is it? I assume one major reason for the 80-character limit is to help
> > the poor sod who will eventually get stuck working with your code on an
> > 80-column fixed width terminal window.
> 
> What environments with that limitation are still in common use?
> It's not the '70s anymore; I think we can safely increase the max
> column width a bit.
> 

I agree. I have my tiling WM setup with two columns, giving each terminal 110
characters of breathing space. I still limit my lines to 78 chars though, if
not for any reason besides text is nice and easy to read at that width, and
everyone else is doing it. I have no reason to change. I've never desired more
characters than that.
-- 
Corey Richardson
  "Those who deny freedom to others, deserve it not for themselves"
     -- Abraham Lincoln

[toc] | [prev] | [next] | [standalone]

#10205

On 2011-07-22, John Gordon wrote:

> In <98u00kFnfiU1@mid.individual.net> Neil Cerutti <neilc@norwich.edu> writes:
>
>> You can fit much more code per unit of horizontal space with a
>> proportionally spaced font. As a result, that issue, while valid,
>> is significantly reduced.
>
> Is it?  I assume one major reason for the 80-character limit is to help
> the poor sod who will eventually get stuck working with your code on an
> 80-column fixed width terminal window.
>

It's also because many people report that it's easier to read text when
it's not wider than ~75 characters.

[toc] | [prev] | [next] | [standalone]

#10207

:

> It's also because many people report that it's easier to read text when
> it's not wider than ~75 characters.

That rule [1] is for paragraphs of prose in proportional text; code is
both written and read differently. While there most likely is an upper
limit, it's going to be different - larger? - for monospace text with
varying natural line lengths whose visual structure helps you to keep
your "place".

Having said that, I use 78 characters, am rarely annoyed by it
(usually by exception text), and see little benefit in breaking from
such a widely obeyed standard.

 -[]z.

[1] http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2

[toc] | [prev] | [next] | [standalone]

#10228

Zero Piraeus <schesis@gmail.com> writes:

> :
>
> > It's also because many people report that it's easier to read text when
> > it's not wider than ~75 characters.
>
> That rule [1] is for paragraphs of prose in proportional text; code is
> both written and read differently. While there most likely is an upper
> limit, it's going to be different - larger? - for monospace text with
> varying natural line lengths whose visual structure helps you to keep
> your "place".

Code is also more densely expressive and provides less redundancy in
expression, and the reader is required to make much finer scrutiny of it
than of natural language text.

I find that the limit of line length for comfortably reading code is
significantly lower than that for English text. “Keep lines less than 80
characters” makes a lot of sense to me in that context.

-- 
 \            “Program testing can be a very effective way to show the |
  `\        presence of bugs, but is hopelessly inadequate for showing |
_o__)                              their absence.” —Edsger W. Dijkstra |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#10258

On 2011-07-24, Ben Finney <ben+python@benfinney.id.au> wrote:
> Code is also more densely expressive and provides less
> redundancy in expression, and the reader is required to make
> much finer scrutiny of it than of natural language text.

The best writing is less redundant than a line of code, not more.
But most people don't have enough time to write that little.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#10121

On Jul 22, 2011, at 12:23, Thomas Jollans wrote:

> On 22/07/11 10:11, Thomas Rachel wrote:
>> Am 22.07.2011 00:45 schrieb Terry Reedy:
>> 
>>> Whether or not they are intended, the rationale is that lining up does
>>> not work with proportional fonts.
>> 
>> Who on earth would use proportional fonts in programming?!
> 
> Why not?

Indeed. Since Windows95 I always use a proportional font for programming:

  http://www.michielovertoom.com/incoming/comic-sans-python.jpg

It's so elegant and gives aesthetic pleasure to look at.

Greetings,

-- 
"If you don't know, the thing to do is not to get scared, but to learn." - Ayn Rand      

[toc] | [prev] | [next] | [standalone]

#10128

On Jul 22, 10:05 pm, Michiel Overtoom <mot...@xs4all.nl> wrote:
> On Jul 22, 2011, at 12:23, Thomas Jollans wrote:
>
> > On 22/07/11 10:11, Thomas Rachel wrote:
> >> Am 22.07.2011 00:45 schrieb Terry Reedy:
>
> >>> Whether or not they are intended, the rationale is that lining up does
> >>> not work with proportional fonts.
>
> >> Who on earth would use proportional fonts in programming?!
>
> > Why not?
>
> Indeed. Since Windows95 I always use a proportional font for programming:
>
>  http://www.michielovertoom.com/incoming/comic-sans-python.jpg
>
> It's so elegant and gives aesthetic pleasure to look at.
>
> Greetings,
>
> --
> "If you don't know, the thing to do is not to get scared, but to learn." - Ayn Rand      


Also it is more optimized. For the same size -- and therefore
readability -- a proportional font packs in more text.

I also find it all the more surprising that python programmers argue
against proportional fonts, given that python is one of the odd
languages that gives semantic significance to white space.

I dont use proportional fonts because the tools are broken.

[toc] | [prev] | [next] | [standalone]

#10130

On Fri, Jul 22, 2011 at 11:43 AM, rusi <rustompmody@gmail.com> wrote:
> Also it is more optimized. For the same size -- and therefore
> readability -- a proportional font packs in more text.

More text == less readability.  This is one of the reasons I limit my
line lengths.

[toc] | [prev] | [next] | [standalone]

#10126

On Sat, Jul 23, 2011 at 3:05 AM, Michiel Overtoom <motoom@xs4all.nl> wrote:
> Indeed. Since Windows95 I always use a proportional font for programming:
>
>  http://www.michielovertoom.com/incoming/comic-sans-python.jpg
>
> It's so elegant and gives aesthetic pleasure to look at.

http://xkcd.com/590/

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web