[Tutor] Sorting a dictionary in one line?

[Magnus Lycka]

At 19:32 2003-01-19 -0800, Terry Carroll wrote:
>First, I didn't know that that was the conventional method; it's just what
>I ended up with.  I guess that I should be pleased that what I ended up
>with was conventional!

Yes! The Python motto "there should be one-- and preferably only one
--obvious way to do it" seems to work! :) Probably, it doesn't work
for everybody, but it seems to work for you and me.

>Second, this is a learning exercise.  If I can learn other ways of
>performing the task, or gain insight into the language in the process of
>trying, that's the point of the exercise.

Sure, I understand that. Sometimes I feel that people try
to push the limits a bit further than they need, trying to
improve things that are both fast, functional and clear, but
trying different things, and testing the limits of oneself
and ones tools is certainly a part of the learning experience.
I hope you enjoy it. I do.

>Finally, if there was a more concise way of doing it and I was missing it,
>I wanted to know what it was.

Sometimes there are shorter ways that should be avoided,
since they become obscure, but in general, I certainly
agree. Less code is better, most of the time.

I've seen that for instance Eric Raymonds write this on
one physical line like this:
   sortedList = xList; sortedList.sort()

That's shorter than two lines... In general, using ; in python
should be avoided, but in this case we might want to view those
to lines of python code as one operation from a conceptual
point of view. In that case, using ; might improve the
clarity of the code. But it will still be on a separate line
before the for-loop.

In C++ I usually advice against stacking operations on each
other like a.b().c(), or a(b.c(), d.e.f()) etc. I want C++
programmers to spread this out over several lines, and to
assign local variables to each part. The reason for this is
that it makes debugging much easier. You can view the parts
of the big statement as local variables in the debugger, and
you can see in what part it fails as you debug line after line.
In Python this is less of an issue, since the tracebacks will
probably show you where the error occurred anyway.

You do have to make a tradeoff here though. On one hand, less
code is in general easier to read, write and maintain. On the
other hand, to many things on one single line will be harder
to understand and debug. Introducing local variables might also
explain the function better if the variable names are well chosen.

I guess the typical thing that you learn in school is to
put each thing on a line and preferably spice the code with
plenty of comments. If you have something, as in most simple
school examples, that could be written in 3 compact lines, it
might be easier to understand (for a beginner at least) if
you write it in 12 lines instead, but if you have a 20 line
function that fits well on the screen, I doubt that people
will understand it better if it grows to 80 lines and won't
even fit on one page if you print it out. At least for me,
code gets much harder to understand if I can't keep all the
relevant parts in my primary field of vision at the same
time. Maybe it's just my poor memory?

You also have to take your audience into consideration. Just
as a book might be too brief for one person and to verbose
for another, the same applies to code. A client of mine
sometimes complains that I put to few comments into my code
and that he doesn't understand it well enough. He is probably
right, but the main problem is that he has too little routine
as a programmer, and I don't think he has grasped the concept
of cbject-oriented programming at all. Also, he looks rather
little in the code (at least as long as it works) and it's about
ten thousand lines by now. Regardless of how good comments I
would put in there, he would be unable to maintain it on his
own. I think he is confused by things that are normal Python
idioms, and I see no reason to make that production code into
a Python tutorial.

"the Practice of Programming" by Kernighan & Pike is a good
book that brings up these issues.

My old Engineering teacher from secondary school always used
to say that lazyness was the most important quality in a
good engineer--then he fell asleep half way into the class.
We felt a bit silly when we visited the big ball-bearing
manufacturer SKF with the class, and he started to snore
loudly during the presentation they held for us... But I
think it was worst for the SKF guy who held the presentation.

Oh well, disregarding his excesses, he certainly had a point!



-- 
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/  mailto:magnus@thinkware.se