Python paradigms

Blake Winton bwinton at
Mon Apr 10 15:35:47 EDT 2000

On 10 Apr 2000 08:31:52 GMT, Nick Maclaren wrote:
>In article <3H4I4.709$4w1.17557 at>,
>Darrell <darrell at> wrote:
>>> x = (a != NULL ? a[i]->weeble : 0) + (b != NULL ? b[i]->wombat : 0)
>>if a != NULL:
>>    x=a[i].weeble
>>if b != NULL:
>>    x=x+b[i].wombat
>>Isn't this more clear?  In fact isn't not much if any longer than the
>>"C" version when you count the parens used.
>No.  Firstly, it relies on an artifact of my example (i.e. that it is
>in an assignment, rather than a test condition or function call) and,
>secondly, the more lines that code takes the harder it is to see the
>function in its entirety.

Now perhaps it's just because I've been forced to switch brace styles at
work, but this comment kind of rubs me the wrong way.  Even on the linux
console (possibly the least configurable text mode I know), you can get
80 lines on the screen at a time.  It's my (not so) humble opinion that
if your functions are 80 lines long, then you're probably doing
something wrong.  Even if you have to break your single line up into
four or five, surely it's not causing your functions to run off the end
of the screen, or if it is, perhaps it's time to break your functions up
a little.

And in my case, I far prefer the second version.  One concept per line
seems like a decent metric to go by, and "x = (a?b:c) + (d?e:f)" seems
like a lot more than one concept to me...

Finally, think of all the whitespace you've saved by not having to use
"}"s all over the place.  ;)

2:54pm up 12 days, 15:28, 1 user, load average: 1.08, 1.02, 1.01

More information about the Python-list mailing list