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

Discussion in 'Python' started by Alex Martelli, Dec 29, 2004.

  1. 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 Martelli, Dec 29, 2004
    #1
    1. Advertising

  2. On Wed, 29 Dec 2004 11:35:18 +0100, rumours say that
    (Alex Martelli) might have written:

    [snip: things to cover in a tentative 2nd edition of the nutshell]

    >and new capabilities of existing modules, such as thread-local
    >storage.


    ....which I most surely missed learning about it. Sometimes it's hard
    following all the changes, and amk's _What's New_ didn't mention it too
    (I'm sending a copy of this post to amk). In case others didn't know
    too, Google's first hit using the obvious query points to:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302088

    which is providing code and hints how to find out more about
    threading.local .

    Yes, Alex, I am sure a second version of the Nutshell would be much
    needed; now and then there are discussions about good Python books, and
    I believe recently someone proposed the Nutshell among others, only to
    get the reply "but it only covers up to 2.2".
    --
    TZOTZIOY, I speak England very best.
    "Be strict when sending and tolerant when receiving." (from RFC1958)
    I really should keep that in mind when talking with people, actually...
     
    Christos TZOTZIOY Georgiou, Dec 29, 2004
    #2
    1. Advertising

  3. Alex Martelli

    Arthur Guest

    On Wed, 29 Dec 2004 11:35:18 +0100, (Alex Martelli)
    wrote:

    >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.


    I understand in advance that my comments are not fully practical:

    The gap in the "market" against which I am currently bumpiong up
    against a wall is in gaining an understanding of threads,
    sub-processes, sockets, signals and such in Python - having no
    background in these concepts from outside of Python.

    Programming concepts up to this level can all (or mostly all)
    succesfully be learned and understood from materials out there
    speaking in Python. As to these concepts, the implicit point of view
    seems to be to leave Python to learn the concepts, and return to
    Python to understand its implementation of the details, once the
    concepts are well grasped.

    It seems to me important that this gap be filled. somehow at some
    point. The advice of "go learn threads in Java" and come back then
    seems a pity. Some of the other concepts which I am confronting I
    understand to be basic for the C programmer. "This is how Python
    implements these C concepts, which we of course all understand".
    My hand has been held nicely, too this point then....

    Learn C and come back? Love to. Don't have the time. I am a
    practicing Python programmer, hoping that can be enough.

    If I want to no more than be able to follow, say, the current Idle
    code of the PyShell module, I can find very little guidance from
    within the canon of Python literature.

    Help?

    Art
     
    Arthur, Dec 29, 2004
    #3
  4. On Wed, 29 Dec 2004 14:05:18 +0200, rumours say that Christos "TZOTZIOY"
    Georgiou <> might have written:

    >[snip: things to cover in a tentative 2nd edition of the nutshell]


    [Alex]
    >>and new capabilities of existing modules, such as thread-local
    >>storage.



    >...which I most surely missed learning about it. Sometimes it's hard
    >following all the changes, and amk's _What's New_ didn't mention it too
    >(I'm sending a copy of this post to amk)


    ....and most promptly amk replied by pointing to

    http://docs.python.org/whatsnew/node13.html

    where it is indeed mentioned. So I stand corrected, mea culpa etc :)
    --
    TZOTZIOY, I speak England very best.
    "Be strict when sending and tolerant when receiving." (from RFC1958)
    I really should keep that in mind when talking with people, actually...
     
    Christos TZOTZIOY Georgiou, Dec 29, 2004
    #4
  5. learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

    Arthur <> wrote:
    ...
    > speaking in Python. As to these concepts, the implicit point of view
    > seems to be to leave Python to learn the concepts, and return to
    > Python to understand its implementation of the details, once the
    > concepts are well grasped.


    Hmmm, well, the concepts are reasonably independent of the programming
    language involved. If anything, threads and processes may be more tied
    to whatever _operating system_ you're using. A very fundamental but
    good introduction to processes (and other such basics) is for example at
    <http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/>, but it
    will be only partially applicable if you need to understand in depth the
    process-model of Windows. But of course this is about the concepts, not
    the practice of programming to interact with them.


    > If I want to no more than be able to follow, say, the current Idle
    > code of the PyShell module, I can find very little guidance from
    > within the canon of Python literature.
    >
    > Help?


    Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
    how to program", chapters 18 (Process Management) and 19
    (Multithreading), pages 613-687? They seem to do a rather workmanlike
    job -- of course, they can't do full justice to the subjects in 75
    pages; and if you don't want to buy a vast, costly 1300-pages tome for
    the sake of those 75 pages, I can't really blame you, either. Still,
    without some clarification of how (if at all) those 75 pages fail to
    meet your learning needs, it's hard to know what else to suggest. And
    what about Norman Matloff's
    <http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf>, the first
    google hit if you're looking for
    python threads
    ? I haven't looked into it, but, again, without some specific
    explanation of how it fails to meet your needs, it's hard to offer
    alternatives.

    It is, of course, out of the question that the Nutshell can get into the
    tutorial business -- MY space budget for the whole "Threads and
    processes" chapter is around 20 small pages, and I personally consider
    it quite a feat to have managed to fit within that compass 4 pages of
    advice on threaded program architecture as well as a down-to-the-bone
    reference to modules threading, Queue, os (process-related subset) _and_
    mmap;-). Still, others _are_ writing Python tutorials, and it does seem
    that books such as "Learning Python" and even "Dive into Python" are
    (understandably, I guess) avoiding the subject... so, pinpointing what's
    being looked for by learners, which Deitel et al, Matloff, etc, are
    missing, might help future editions and versions of such books...


    Alex
     
    Alex Martelli, Dec 29, 2004
    #5
  6. (Alex Martelli) writes:

    > 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.


    I found the discussion of unicode, in any python book I have, insufficient.

    Thomas
     
    Thomas Heller, Dec 29, 2004
    #6
  7. Alex Martelli

    djw Guest

    >
    >
    > I found the discussion of unicode, in any python book I have, insufficient.
    >
    > Thomas



    +1

    Don
     
    djw, Dec 29, 2004
    #7
  8. Alex Martelli

    Guest

    As an already-experienced programmer, I came to Python via this book
    and still use it as my primary reference.

    As a Python beginner, I had a difficult time with the section on
    "Slicing a sequence" (p. 47). In particular, a better explanation and
    examples of negative indicies would be helpful.

    This is nitpicking in what I consider to be a very good book. I hope
    the second edition flies.

    Cheers,
    Steve
     
    , Dec 29, 2004
    #8
  9. 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).
    >
    > 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.


    * code coverage tools for python code (testing your tests).
    * new-style classes forward and old-style shrunk. "best practices"
    such as "always super(class, self).__init__(...)" and why even if
    why is only a forward reference. Using Left(object), Right(object),
    Top(Left, Right) would be good for the example.
    ** Fix the examples in "Inheritance in new-style object model", the
    diagram, and the following example in "cooperative superclass
    method calling" to use the same hierarchy. I personally prefer
    the A(object), B(A), C(A), D(B,C) hierarchy, but they should
    match.
    * implementing types/classes in C -- a checklist w/ advice on testing.

    --Scott David Daniels
     
    Scott David Daniels, Dec 29, 2004
    #9
  10. Alex Martelli

    Fuzzyman Guest

    Fuzzyman, Dec 29, 2004
    #10
  11. Alex Martelli

    Guest

    I like the current edition. Since it is a reference work, I would like
    to see it in a CD-ROM as well as in print, either packaged with a book
    or as part of a Python CD Bookshelf, analogous to the other CD
    bookshelves O'Reilly offers.
     
    , Dec 29, 2004
    #11
  12. Alex Martelli

    Aahz Guest

    Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

    In article <1gpkcn8.1ukbssevczr9mN%>,
    Alex Martelli <> wrote:
    >
    >Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
    >how to program", chapters 18 (Process Management) and 19
    >(Multithreading), pages 613-687? They seem to do a rather workmanlike
    >job -- of course, they can't do full justice to the subjects in 75
    >pages; and if you don't want to buy a vast, costly 1300-pages tome for
    >the sake of those 75 pages, I can't really blame you, either.


    Except that it's a really, really piss-poor book. That's an opinion
    which I believe you've agreed with previously.

    >And what about Norman Matloff's
    ><http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf>, the first
    >google hit if you're looking for
    > python threads
    >? I haven't looked into it, but, again, without some specific
    >explanation of how it fails to meet your needs, it's hard to offer
    >alternatives.


    That's actually pretty good.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "19. A language that doesn't affect the way you think about programming,
    is not worth knowing." --Alan Perlis
     
    Aahz, Dec 29, 2004
    #12
  13. Alex Martelli wrote:

    > the coverage of Twisted and adding just a few things (numarray --
    > perhaps premature to have it _instead_ of Numeric, though; dateutils,


    You might want to keep in touch with the scipy/numarray gang on this particular
    topic. An effort is currently under way to make scipy work with numarray, and
    matplotlib already works with numarray out of the box. These two facts will,
    I think, greatly accelerate the adoption of numarray and the transition away
    from Numeric. There are a few people (like me, unfortunately), who can simply
    not use numarray because of the small array instatiation overhead. But that
    subcommunity tends to know enough to be able to deal with the problems by
    itself. Since numarray is indeed the long-term array core for Python, I think
    the book would be better off by covering it. Numarray is actively developed,
    and vastly better documented than Numeric.

    A mention of the particular problems with numarray might be a good idea, so
    that readers are aware of Numeric and where it may still be preferable to
    numarray, but with the understanding that it's a (shrinking) niche. Hopefully
    one day that niche will shrink to zero, but that is going to take time and
    work.

    Finally, I think in this section a mention of the overall scipy project would
    be a good idea. Scipy is the central meeting point for most scientific
    computing projects in python, and therefore a natural reference for most users
    of numarray/numeric. Amongst other useful things at the scipy site, there's a
    community maintained wiki of links to python-based projects of scientific
    interest:

    http://www.scipy.org/wikis/topical_software/TopicalSoftware

    Regards,

    f
     
    Fernando Perez, Dec 29, 2004
    #13
  14. Alex Martelli

    Craig Ringer Guest

    On Wed, 2004-12-29 at 23:54, Thomas Heller wrote:

    > I found the discussion of unicode, in any python book I have, insufficient.


    I couldn't agree more. I think explicit treatment of implicit
    conversion, the role of sysdefaultencoding, the u'' constructor and
    unicode() built in, etc would be helpful to many.

    A clear explanation of why Python strings, despite being assumed to be
    ASCII, can contain any 8-bit data in any text encoding (or no text
    encoding at all) may also help newbies.

    I spent a while fighting to understand the way python handles encodings
    a while ago and benefited significantly from it - but there really needs
    to be a good explanation. The relationship between 'str' and 'unicode'
    objects, the way implicit conversion works with sysdefaultencoding, and
    how explicit conversions between encodings and to/from unicode, in
    particular, need attention.

    It'd also be REALLY good to mention the role of, and importance of, the
    coding: line. An explanation of its relationship with the interpretation
    of strings in the script, and with the sysdefaultencoding, would also be
    helpful, as IMO the script encodings PEP only really makes sense once
    you already understand it.

    It wouldn't hurt to point C extension authors at things like the 'es'
    encoded string format for PyArg_ParseTuple to help them make their code
    better behaved with non-ascii text.

    --
    Craig Ringer
     
    Craig Ringer, Dec 29, 2004
    #14
  15. Alex Martelli

    Arthhur Guest

    Re: learning about threads and processes (was Re: what would you like to see in a 2nd edition Nutshell?)

    On Wed, 29 Dec 2004 16:41:23 +0100, Alex Martelli wrote:
    >
    > Hmmm, well, the concepts are reasonably independent of the programming
    > language involved. If anything, threads and processes may be more tied
    > to whatever _operating system_ you're using. A very fundamental but
    > good introduction to processes (and other such basics) is for example at
    > <http://en.tldp.org/HOWTO/Unix-and-Internet-Fundamentals-HOWTO/>, but it
    > will be only partially applicable if you need to understand in depth the
    > process-model of Windows. But of course this is about the concepts, not
    > the practice of programming to interact with them.


    Too basic. Doesn't speak to the "intermediate".

    I'll have you know, sir, you are speaking to someone who is
    quite intermediate, at least in mediocre way. Hummph ;)


    >> If I want to no more than be able to follow, say, the current Idle code
    >> of the PyShell module, I can find very little guidance from within the
    >> canon of Python literature.
    >>
    >> Help?

    >
    > Hmmm - have you looked at Deitel, Deitel, Liperi, Wiedermann, "Python
    > how to program", chapters 18 (Process Management) and 19
    > (Multithreading), pages 613-687? They seem to do a rather workmanlike
    > job -- of course, they can't do full justice to the subjects in 75
    > pages; and if you don't want to buy a vast, costly 1300-pages tome for
    > the sake of those 75 pages, I can't really blame you, either. Still,
    > without some clarification of how (if at all) those 75 pages fail to
    > meet your learning needs, it's hard to know what else to suggest. And
    > what about Norman Matloff's
    > <http://heather.cs.ucdavis.edu/~matloff/Python/PyThreads.pdf>, the first
    > google hit if you're looking for
    > python threads


    I never gotten to page 613 of any book in my life ;)

    But the Matloff piece you site is in fact helpful to the intermediate.

    Frankly not sure how I missed it in past searches. "Python threading" as
    a google buries it a bit, but not that deeply.

    This also comes up on a fresh search, and is to the point and at the level
    of interest. It is also recent:

    http://linuxgazette.net/107/pai.html


    > ? I haven't looked into it, but, again, without some specific
    > explanation of how it fails to meet your needs, it's hard to offer
    > alternatives.


    The problem is when one starts off explaining threads by reference to
    processes, I already have a practical problem. Which, under what
    circumstances.

    Again referring back to the Idle code, class ModifiedInterpreter in the
    PyShell module:

    Within the space of a simple class, we are spawning
    a subprocess via:

    self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args)

    and a rpc client listening to a socket via:

    self.rpcclt = MyRPCClient(addr)

    which can be interrupted via a thread ala:

    threading.Thread(target=self.__request_interrupt).start()

    And then it gets a little complicated, to an intermediate ;)

    Guess I am hoping to get to understand it as architecture, as well as as
    code.

    This happens to be another piece of code I am trying to digest, which
    allows one to experiment with building PyGTK widgets from an interactive
    prompt:

    http://www.pygtk.org/pygtktutorial/examples/pygtkconsole.py

    which uses os.fork and signals in its architecture, but no threads, as
    opposed to this CookBook recipe:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109

    which accomplishes a very similar functionality using threads as a
    fundamental part of its strategy.

    The closest thing I can think of as the kind of book I would love to see
    is one similar to Steve Holden's book on web programming, which explained
    lower level internet proctocols at the same time as it explained their
    Python implementation.

    Wonder what Steve's are doing this week? ;)

    Art
     
    Arthhur, Dec 29, 2004
    #15
  16. In article <1gpjz0o.umrpws1pjdekyN%>,
    (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).
    >...


    Since you were kind enough to ask...what I'd really like is a better
    better index and better organization, so I can more quickly and easily
    locate info on a particular topic.

    Nutshell has some wonderful in-depth discussions of certain topics and
    I'm glad I own it, but I find it too hard to use for everyday questions
    (which was not at all what I expected for a "nutshell" book). I usually
    start with the html help (if I know the module I need or have a firm
    guess as to which other manual to read) or Python Essential Reference
    (other cases), then go to Nutshell if I'm still lost or if I remember it
    has a good section on the topic of interest.

    -- Russell
     
    Russell E. Owen, Dec 29, 2004
    #16
  17. Alex Martelli

    c d saunter Guest

    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).

    : 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,
    Probably not a practical sugestion, but have you considered
    ctypes? I know it's proved invaluable to our group at university - we
    like to make Python work with so many bits of weird hardware with vendor
    supplied libraries etc ...

    Perhaps a more resonable sugestion would be a short section on integration
    with native systems, e.g. an intro/overview to (non exhaustive list):

    psyco
    scipy.blitz/weave
    ctypes
    pyrex

    A detailed look at these is probably outside the scope of Nutshell, but
    they all represent intreresting areas. Perhaps the section could end with
    some words on PyPy.

    Cheers,
    cds
     
    c d saunter, Dec 29, 2004
    #17
  18. Alex Martelli

    RM Guest

    Alex Martelli wrote:
    > I still
    > believe Tkinter coverage is going to help more readers.


    Alex,

    I know this can be a can of worms. But honestly, I wonder what do you
    base that idea on.

    -Ruben
     
    RM, Dec 29, 2004
    #18
  19. As a tester, my vote goes to extending the "Testing" subsection of the
    "Testing, debugging and optimizing". I'd like to see more testing tools
    discussed there. Maybe py.test, PyFIT, and possibly others.

    Grig
     
    Grig Gheorghiu, Dec 29, 2004
    #19
  20. Alex Martelli

    Steve Holden Guest

    RM wrote:

    > Alex Martelli wrote:
    >
    >>I still
    >>believe Tkinter coverage is going to help more readers.

    >
    >
    > Alex,
    >
    > I know this can be a can of worms. But honestly, I wonder what do you
    > base that idea on.
    >
    > -Ruben
    >

    Tkinter is a part of the Python core, and so will be available to the
    majority of beginners. Tkinter is also likely to be supported (by Tcl)
    in Linux and other Unix-like environments, although with a slightly
    lower level of ubiquity.

    I suspect Alex is considering availability at least as strongly as the
    technical merits of the packages.

    And, when all is said and done, beginners shouldn't have to go download
    stuff before beginning to noodle round with GUIs.

    regards
    Steve
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
     
    Steve Holden, Dec 29, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    609
    Roedy Green
    Apr 13, 2006
  2. Replies:
    0
    Views:
    528
  3. Helmut Jarausch

    Python in a nutshell - new edition ?

    Helmut Jarausch, Jun 28, 2006, in forum: Python
    Replies:
    7
    Views:
    290
    John Salerno
    Jun 29, 2006
  4. Sandro Tosi
    Replies:
    8
    Views:
    290
    Sandro Tosi
    Jan 11, 2009
  5. Benjamin Peterson

    what features would you like to see in 2to3?

    Benjamin Peterson, Mar 22, 2009, in forum: Python
    Replies:
    4
    Views:
    227
    Benjamin Peterson
    Mar 23, 2009
Loading...

Share This Page