<br><br><div class="gmail_quote">On Thu, May 21, 2009 at 11:01 AM, Ben Finney <span dir="ltr"><<a href="mailto:ben%2Bpython@benfinney.id.au">ben+python@benfinney.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Jeremiah Dodds <<a href="mailto:jeremiah.dodds@gmail.com">jeremiah.dodds@gmail.com</a>><br>
writes:<br>
<div class="im"><br>
> hmm, the 80-character convention does not stop me from unconsciously<br>
> writing really complex list comprehensions, I just write them like so:<br>
><br>
> def foo(f, a, b, c):<br>
>     return [[((f(x,y) * i, i) if i % 2 else 0)<br>
>                 for i, x in enumerate(a)<br>
>                 if f(y, x) == a + x]<br>
>               for y in [c(z) for z in range(a, a*b+c, c)]]<br>
><br>
> not that that's really any better.<br>
<br>
</div>On the contrary, I find that *much* easier to grasp than the same<br>
statement on a single line. You have been required, by choosing to<br>
follow the 80-column limit, to choose points at which to break the line;<br>
and have responded by breaking it up into conceptually discrete chunks<br>
and indented to suggest the structure.<br>
<br>
This example is, for me, a very convincing (anecdotal) demonstration of<br>
why an 80-column limit is a good constraint to follow.<br>
<div class="im"></div></blockquote><div><br>Oh, yes - I consider it much easier to read than the single-line equivalent. What I meant by "not that that's really any better" was more along the lines of "that statement should probably be refactored". It's very rare that I run into a case where a convoluted list comprehension like that isn't better written some other way. Sometimes I end up with stuff like that when I've made incorrect assumptions while designing a program, etc.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
> But yeah, this is all anectodal evidence and personal taste, as<br>
> Raymond points out.<br>
<br>
</div>Yet it's also more than that; to call it “personal taste” is to imply<br>
that it's nothing more than aesthetics. If that's all it were, I'd care<br>
far less for changes in convention.<br>
<br>
I consider it rather more importantly a matter of software ergonomics,<br>
which should therefore not be changed unless there's good supporting<br>
evidence that the proposed change results in improvement.<br>
</blockquote><div><br>I tend to agree. That's very well-said.<br> </div><br></div><br>