Re: [Tutor] Code Readability (was: Recursion and List Comprehensions)
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 <[EMAIL PROTECTED]> 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. > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Code Readability (was: Recursion and List Comprehensions)
> > 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 the code later on. 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. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Code Readability (was: Recursion and List Comprehensions)
Since when is elegance a dirty word? Elegance is the soul of good programming. A simple and graceful solution to the widest number of cases, efficient and easy to understand in application. Sometimes subtle, but always beautiful. In language design, software architecture, algorithms, it is the rushing light of clarity that banishes dark and smelly corners. It's side effects are many--reusable code, effortless speed, painless maintenance, reduced complexity. The dreams shared by physicists, mathematicians, and engineers, are dreams of elegance. It is heartbreaking to see a concise and useful term maligned by dense one-liners, which are seldom anything except hard to read. Simple and short ain't the same thing. And having indulged in possibly very off-topic interlude, let me point out that recognizing a donut when you see it, doesn't make you a baker. Trust me, I'm not baking donuts. And judging by the amount of Escher-like pretzels that continute to be baked in the world, we have a long ways to go before we get more than the occasional sighting or passing whiff of something sweet and round with a hole in the middle. . Take care, Andrew On 10/28/05, Carroll, Barry <[EMAIL PROTECTED]> wrote: > Kent Johnson <[EMAIL PROTECTED]> wrote: > > <> > > >>PS Don't get too crazy about eliminating intermediate variables, they can > >>make the code more readable. > >> > >>Kent > > 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. > > Barry > > > ___ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
