what would you like to see in a 2nd edition Nutshell?
yaipa at yahoo.com
Thu Dec 30 15:55:20 CET 2004
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
> 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
> edition of the Cookbook -- Python hasn't changed drastically between
> and 2.4, just incrementally. Language and built-ins additions I'd of
> course cover -- decorators, custom descriptors (already in 2.2 but
> 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
> storage. Outside of the standard library, I was thinking of
> 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,
> example; modules asyncore and asynchat, probably) to make space for
> of the additions.
> I haven't take any real decisions about it, yet, except one: I'll
> 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
> welcome, either privately or right here. Thanks in advance -- _and_
> apologies in advance because I know I just won't be able to
> all the requests/advice, given the constraints on book size &c.
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
Alex, thanks for all the great work.
More information about the Python-list