Python Cookbook (was: extract elements of n char from a list)

[Fernando Perez]

> The book looks very nice, btw. Good job,
> 
> 
> I just got the Cookbook yesterday, and it *does* look good!  I believe we
> can primarily thank Alex Martelli for that -- from what I saw, he put an
> enormous amount of work into organizing, cleaning and improving the content.
> In fact, I wouldn't be suprised to learn that he wrote all the chapter
> intros too <wink>.

Well, I'd like to make a few comments on it. First, It kept me up last 
night until 3am, so you guys owe me a few hours of sleep :) Overall, I 
think you all did a _fantastic_ job. I highly recommend this to anyone 
wanting to learn not just about python solutions, but in general about 
intelligent ways of solving real-life problems in various areas of 
computing.

This isn't a review, since I only paged through it (cover to cover 
though). But a few points struck me as I was reading:

1. Even though it has many authors for the recipes, the book managed to 
remain very cohesive in tone and style. You can feel enough differences 
to hear the 'community voices', but not to the point of being distracted 
by them. Maintaining that balance was IMHO a tough act to pull off, and 
I think the editors succeeded admirably.

2. In a past life I kept the Perl cookbook semi-permanently on my desk, 
so I was drawn to making a mental parallel between the two. Without 
wanting to disparage the Perl CB (which is a remarkable piece of work), 
I was struck by a fundamental difference between the two.

My main use of the Perl CB was for situations of the type 'I know 
_logically_ how to do what I want, but how can I manage to get this 
$@%#{}~ language to do it?' (for the perl non-initiated, that was not an 
expletive but simply a short sample of the most commonly used characters 
in the language ;). For example, often needing complicated nested 
structures (e.g. hashes of hashes of arrays), I constantly needed to 
look up the deeply quirky syntax needed to keep track of such things, 
since it's subtle enough that you make mistakes unless you use it every 
day. That gets old quick.

With python, that problem never arises, and the book reflects it. 
Instead of being devoted to reminding you how to do things you should be 
able to do without  a book, it's mostly a discussion of the type 'here's 
a common problem for which naive solutions can have subtle pitfalls, and 
here are various ways to tackle it with real intelligence and power'. 
And python being such a clear language, it is a perfect one to express 
the ideas just discussed in a concrete implementation.

So in a sense I'd argue that the python CB reads almost more like an 
algorithms/computer science book than a 'python' book. It so happens 
that the ideas discussed are illustrated in python. To me that is a huge 
virtue (the power of generality) and a great testament to the quality of 
python as a language.

Of course I'm not arguing that it's going to replace Knuth's series any 
time soon ;). But it was refreshing to me to read often a discussion of 
the various approaches in terms of their asymptotics and even of the 
balance of the fixed additive or multiplicative constants involved. I 
felt like I was not just learning python, but simply learning. That's 
good: a nice balance of (reasonably) 'deep thought' and practicality.

3. Here and there I found recipes that to some extent could qualify as 
workarounds for quirks in either the language or the library. While 
that's great to have, it would probably be nice to keep a list of such 
things as candidates for enhancements (especially the library ones, 
which are far less sensitive and controversial than language changes).

One that jumps to mind is recipe 4.17, p.143 on how to write a mkdirs 
function which doesn't crash on pre-existing directories. That's the 
kind of thing for which adding a keyword argument to the existing 
functions can be a great solution. I think of keyword arguments like 
command line switches on the shell, as a way of extending the life and 
usefulness of functions without disrupting their core interface. One 
could for example add a 'quiet=None' option which if set to true would 
make os.makedirs() behave like the proposed mkdirs(). Just a random idea...

So I think the book could be a nice base for a check list of things that 
sometimes require less than elegant solutions, and for which a fix is 
easy and non-disruptive. I know that core language changes are in a 
different league, but often small improvements to functions can make 
people's life easier without any significant drawbacks.

At any rate, congratulations to all the authors, and a big applause to 
the editors. I highly recommend this book to the python crowds (and even 
to seasoned programmers in other languages, who will probably be seduced 
by the clarity with which python can express often subtle and powerful 
solutions).

Cheers,

f.