[Tutor] Code Readability (was: Recursion and List Comprehensions)

[Andrew P]

Sorry.  *blush*  That was some late Friday night craziness.  I just
looked at the code being discussed:

retList=[word[pos]+item for item in permute3(word[0:pos]+word[pos+1:])]

And really didn't want to anybody to confuse that with Python's idea
of elegance.

List comprehensions can get pretty horrible when combined with nested
functions and/or slices and/or multiple implicit loops.  One of the
few areas where Python can get really twisted.

That's a great point, Danny. For me, elegance is an admirable goal
under any circumstance, but includes all the aspects I listed. 
Effeciency -and- understandability.  Throw it under the umbrella of
"graceful" :)

The tools we use are far from perfect, and there are still plenty of
"aha!" moments to go around.  In the real world the fast and ugly
usually go hand in hand.  I'm an optimist, tho.

Anyway, sorry to go so far off topic.  Oh, and by the way, I loved
'The Psychology of Programming'.  That was a really entertaining book,
and thanks again for recommending it.

Andrew

On 10/29/05, Danny Yoo <dyoo at hkn.eecs.berkeley.edu> wrote:
>
> > > I agree.  When writing for keeps (i.e. production code) I prefer
> > > clarity and ease of maintenance over 'elegance' or 'trickiness'.
> > > This exercise is intended, in part, to sharpen my understanding of
> > > Python idioms.  If I can write highly idiomatic code that works,
> > > chances are better that I will be able to decipher it when I come
> > > across it elsewhere.
>
> > Since when is elegance a dirty word?
>
> It's not.  But there are tradeoffs.  As a concrete example, we can take a
> look at Bram Cohen's fairly recent request for a pure-Python suffix tree
> implmementation:
>
>     http://www.livejournal.com/users/bramcohen/22069.html
>
> He's specifically requesting for an implementation for a data structure
> algorithm that is easy to maintain, and he's willing to sacrifice the
> elegant optimal solution!  But that's because he wants to make sure he can
> understand
> I'm not sure I agree with Bram --- the "Ukkonen" algorithm for building
> suffix trees isn't bad, and I can probably cook it up if I'm careful ---
> but I can see why he values a simple implementation.
>
>
d the code later on.
>