what would you like to see in a 2nd edition Nutshell?

[yaipa]

Alex Martelli wrote:
> I'm considering proposing to O'Reilly a 2nd edition of "Python in a
> Nutshell", that I'd write in 2005, essentially to cover Python 2.3
and
> 2.4 (the current 1st edition only covers Python up to 2.2).
>
> What I have in mind is not as complete a rewrite as for the 2nd vs
1st
> edition of the Cookbook -- Python hasn't changed drastically between
2.2
> and 2.4, just incrementally.  Language and built-ins additions I'd of
> course cover -- decorators, custom descriptors (already in 2.2 but
not
> well covered in the 1st edition), importing from zipfiles, extended
> slicing of built-in sequences, sets, genexps, ... and also major new
> standard library modules such as (in no special order) optparse,
> tarfile, bsddb's new stuff, logging, Decimal, cookielib, datetime,
> email... and new capabilities of existing modules, such as
thread-local
> storage.  Outside of the standard library, I was thinking of
expanding
> the coverage of Twisted and adding just a few things (numarray --
> perhaps premature to have it _instead_ of Numeric, though; dateutils,
> paramiko, py2app...).  Since the book's size can't change much, I'll
> also have to snip some stuff (the pre-email ways to deal with mail,
for
> example; modules asyncore and asynchat, probably) to make space for
all
> of the additions.
>
> I haven't take any real decisions about it, yet, except one: I'll
keep
> covering Tkinter, rather than moving to, say, wxPython (no space to
> _add_ wx coverage while leaving Tk intact - having to choose, I still
> believe Tkinter coverage is going to help more readers).  Just about
> everything else is still to be finalized in my mind...
>
> So, if there's any advice or request about a 2nd edition of the
> Nutshell, this is the right time for y'all to let me know.  Feedback
is
> welcome, either privately or right here.  Thanks in advance -- _and_
> apologies in advance because I know I just won't be able to
accomodate
> all the requests/advice, given the constraints on book size &c.
>
>
> Alex

Alex,

1. interfacing to 'C' code, ie Pyrex or such.
2. explaining why explicit type casting is not Pythonic ]:-)
.  Why you should use a .lib module like Pyrex if you really need
explicit type casting and not demand that it become a part of core
Python.

Alex, thanks for all the great work.

Cheers,

  --Alan