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

[Alex Martelli]

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

 

[Christos TZOTZIOY Georgiou]

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

 

[Arthur]

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

 

[Christos TZOTZIOY Georgiou]

[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

 

[Alex Martelli]

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

 

[Thomas Heller]

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

 

[djw]

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

Thomas

+1

Don

 

[terraplane]

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

 

[Scott David Daniels]

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
(e-mail address removed)

 

[Fuzzyman]

I second that....
Regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

 

[beliavsky]

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.

 

[Aahz]

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.

 

[Fernando Perez]

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

 

[Craig Ringer]

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.

 

[Arthhur]

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

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

 

[Russell E. Owen]

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

 

[c d saunter]

Alex Martelli ([email protected]) 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

 

[RM]

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

 

[Grig Gheorghiu]

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

 

[Steve Holden]

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