What does "Sparse is better than dense" mean? (Python Zen)

[Mark McEahern]

[Alex Martelli]
> It definitely doesn't make any difference to the compiler, but
> it makes a huge difference to ME, as a human reader of the code,
> to avoid wasting a line and thus fitting more lines onto a screen.
>
> This is particularly important with small screens, such as the
> Sharp Zaurus' 300x200 screen or thereabous, but even on large
> screens it lets me use a larger and thus more readable font for
> any given amount of lines that I need to see at once on-screen.

I hadn't thought of different screen sizes.  That's a good point.

> Personally, I have no difficulty whatsoever "visually scanning"
> these constructs -- the lack of any indented line under the keyword
> stands out and quite effortlessly makes my eyes glide rightwards.

The advantage I find in using two lines for for these constructs is that I
don't have to parse the keyword and notice the lack of an indented line.  I
speculate that the contour of indentation is easier to see "at a distance"
and can be done without having to see/parse the individual keywords.

Of course, the other explanation for my sentiments is that I'm just stubborn
and I haven't really tried to cultivate an appreciation for this other
approach.  I remember having a strong dislike for using underscores in
identifiers, but I've gotten used to that.

> I MUCH prefer to use entirely blank lines for separation of
> _semantically *meaningful* blocks_ of code, rather than breaking
> every compound statement into more lines than needed, most
> particularly when such a compound statement corresponds to
> a single "compound thought".

Yes, I'm a fan of using blank lines to separate chunks.  I hadn't thought of
applying that to the short compound statements.  I appreciate your example:

> style B:
>
> while True:
>     prelim_one()
>     X = prelim_two()
>     Y = another_thing(X)
>
>     if X > Y: break
>
>     yet_another(X, Y)
>     prepare_next(X+Y)
>
>
> Style B forgoes the wanton linebreak at the 'if' and invests
> that line (plus another presumably saved elsewhere by using
> no wanton breaks:-) to make the loop's exit condition stand
> out much better.

> I suspect we'll have (at best) to agree to disagree on the
> specifics of this.

Well, I'm glad I piped up--I received the unexpected gift of a well
articulated view counter to my own.

Thanks!

Cheers,

// mark

p.s. Anecdotally, I was looking at the source for a Python C extension early
this morning and it had what seemed like completely inconsistent
indentation.

	// all of these styles appeared in the same file...
	for (...) {
      statements
	}
	if (...) {
        statements
      }
      if (...) {
          statements
      }

I didn't investigate, but this may have been at least partially due to weird
voodoo in my .emacs file--but I doubt it.

So I think I was even more sensitive than usual to the joy of Python's
enforced indentation rules.

-