Should I write a book on Python Metaprogramming ?

Alex Martelli aleax at aleax.it
Mon May 5 03:41:13 EDT 2003


David Mertz wrote:

> Hi gang,
> 
> Regular readers know who I am... so I won't bother with any more than
> the overblown bio in the proposal text itself.
> 
> Here's the story though:  For a number of months, I have had in mind the
> idea of writing a book called _Metaprogramming in Python_.  A book is a
> lot of work, and not a lot of money--and the more I think about it, the
> more I am a little apprehensive about really doing the title justice
> (and in a way the genuinely helps readers).  Nonetheless, I think I can
> claim with only slight immodesty that no one, other than perhaps the
> Martellibot, would do a better job with this particular subject.

Thanks for the kudos!  But, all modesty apart, you may indeed be right,
in terms of the intersection of the sets of people who have such exoteric
curiosities AND are proven book-writers.  And I personally do not intend
to write such a book (I _do_ dream of covering such advanced issues, not
as deeply as you will, as part of the book I dream about, which would be
about design patterns and OO programming in general, with Python used as
the main illustration language).


> So here's my questions to c.l.py.  Would you want a book along the below
> lines at all?  Do you only want it if it focusses closely on Python?  Or

Personally, yes, and indeed I think it would help to focus on 2.3 only
AND only on the newstyle object model within it -- the quirks and anomalies
of the classic object model would IMHO be a distraction, not an addition,
to a book that, if properly focused, might charm its intended audience.

> would you rather have a book that addressed several languages fairly
> equally, with Python just one among them?  Are the outlined chapters the
> ones you would expect?  Or is something missing?  Or unnecessary?
> Assuming the suggested chapters point in the right directions, what
> specific topics would you want to see covered within each one?

Personally, I would suggest a sharper distinction between:
  -- clear tutorial+reference illustration of the TOOLS available in 
     each category (with toy examples just to show how they work);
  -- design patterns showing appropriate USE of said tools (with
     examples taken from existing programs where they are used or
     could/should have been used -- "taken" as in "excerpted");
  -- substantial illustrative examples (made up for the purpose)
     showing how a set of tools could be used in practice, or, even
     more usefully, how two different sets could alternatively be
     used and what are the tradeoffs in choosing between them.

I guess you could do that within each chapter, but that might make
it harder to compare and contrast.  I believe your target audience,
which is composed of very advanced programmers, does not necessarily
need the step-by-step motivation that shows all about a given tool
or approach right after it's introduced -- it's easily mature enough
to appreciate a sharper separation in two or three parts as above.

If you could ensure including exercises (some with solutions, other
without) this would very substantially increase the potential worth
of your book as a textbook in some advanced university course.

> Table-of-contents:
> 
>   I.    Introduction to Metaprogramming.
>   II.   Behavior protocols for Python objects
>   III.  Overloading operators and enhancing basic datatypes.

Aren't II and III rather overlapping?  Perhaps they should be
merged, with short shrift given to the basics and more care
about exoteric parts.

>   IV.   Higher order functions.
>   V.    Function and class factories.

Again, isn't there some overlap here (less than between II/III)?

>   VI.   Metaclasses.
>   VII.  Code generators and code parsers.

Do you intend to cover iterators and generators and their use
and (arguably) abuse?  If so, where would that coverage fit?


I really hope the book eventuates -- particularly because I look
forwards to reading it and picking up a trick or two myself!-)


Alex





More information about the Python-list mailing list