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

[Alex Martelli]

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

Overall, yes, it's not a book I'd heartily recommend. But, is anything
wrong, specifically, with chapters 18 and 19? They seem OK to me.


Alex

 

[Alex Martelli]

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.

Thanks! BTW, thanks first and foremost to Holger Krekel (who was a very
"activist" tech reviewer and specifically contributed a recipe for this
purpose), there's what I believe is a pretty good treatment of Unicode
in the Cookbook's forthcoming 2nd edition -- still "insufficient" in
some sense, no doubt (it IS just a few pages), but, I believe, pretty
good. Nevertheless, I'll ensure I focus on this in the 2nd ed Nutshell,
too.

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.

Good sub-point, thanks.


Alex

 

[Alex Martelli]

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.

Good point, thanks.

This is nitpicking in what I consider to be a very good book. I hope

And thanks for this, too!


Alex

 

[Alex Martelli]

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.

Well, I _am_ going to cover or at least "mention" numarray -- my
question was on whether I can _drop_ Numeric in favour of numarray. In
good part _because_ numarray has good docs, it may be less crucial for
me to cover it thoroughly, than I felt it was for Numeric. Three years
ago, numarray was barely a blip on the radar, if that; three years from
now, the same may be true of Numeric; but right now, I get some sense
that we're "in transition" -- that numarray needs and deserves coverage
or at least extended mention, BUT nevertheless it might be premature to
drop the coverage of 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.

Right -- and if I can get the 2nd ed of the Nutshell out within 2005, it
may be too early to say that Numeric has shrunk to the vanishing
point... so I may still need to have both in...

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

Most definitely a good idea, thanks. Indeed, the lack of mention of
scipy _is_ a wart in the 1st ed -- as my excuse I can only explain that
I was _so_ focused on being focused... I ended up excising even all
mentions of my own baby, gmpy...!-) But yes, scipy _will_ most
definitely get a mention this time around -- thanks for reminding me!-)


Alex

 

[RM]

What you say is true. However, I didn't think the target audience of
this book was newbies. Python newbies yes, but not programming
newbies. For programming newbies I would recommend the "Learning
Python" book instead.
The availability argument, however, is a good point.

 

[Alex Martelli]

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.

Thanks for the advice! What I have now is the best organization I was
able to conceive -- and I have no current ideas on how to enhance it.
Any _suggestions_ will be truly welcome; somehow, I don't see "make it
better" as a _suggestion_... if I _knew_ how to organize it better, I
would, of course.

Indexing is a completely separate issue, mostly done by O'Reilly outside
of my control; can we please focus on _organization_, which _is_ almost
entirely in my hands...

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

Indeed, this is definitely not what I was aiming for, and if it's a
widespread issue which all reviews of the book I read managed to hide
it's crucial for it to come out -- whence my thanks. But I need more
help to understand what makes the book's organization so feeble for you,
and whether the issue is widespread so that I need to revolutionize the
book's organization... or whether such a revolution wouldn't hurt the
many readers who appeared sort of OK with the current structure...

Thanks in advance for any further input -- and that applies to others
just as much as to you (meaning: o future potential readers, if you find
the current organization of the book ok, please do speak up -- if only
those who prefer changes are gonna speak, then changes are likely!-).


Alex

 

[Alex Martelli]

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

Yes, I was considering mentioning or covering ctypes as part of an
expansion of the "Extending Python *without* Python's C API" section
which currently mentions pyfort, f2py, SCXX, CXX, Boost, SWIG, pyrex,
weave/blitz, and the use of COM (on Windows only). All of those
mentions are on p. 545, meaning that it's a very crowded section, of
course;-) [[ and yet it's missing lots of stuff such as sip etc...!-)
]]. I do have a ctypes recipe in the "extending and embedding" chapter
of the Cookbook's 2nd edition, and I was really glad to get it because I
like ctypes a lot (the Pyrex recipe I had to request specifically from
my good friend Peter Cogolo -- requests mailed to the pyrex mailing list
having produced no answer whatsoever).

So -- ctypes is definitely getting a _mention_, at least... the issue
remains of whether we're talking one paragraph, like for all other
extending-tools that were already thus mentioned in the 1st edition, or
a couple of pages (I can't possibly spend 2-3 pages on each of a dozen
extending tools, much as I'd love to!).

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

I'm missing psyco, out of these -- unsure whether it should be in the
optimization chapter or in the extending one. But again, mostly, the
issue is "just mention -- or _cover_...?".

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.

Speaking as somebody who's participated in more than half of the pypy
sprints and hopes for more, I think pypy needs to be mentioned much
earlier, together with other "alternate implementations of Python".

I do agree that vast coverage is outside the scope that the Nutshell's
size lets me aim for. However, mere mention appears to lead to a
serious risk of the pointer being entirely missed -- e.g. despite being
interested in these issues you appear to be unaware of p. 545 (1st ed).
Hmmm -- maybe I need to strike some kind of balance here (so what else
is new...;-).


Thanks!

Alex

 

[Aahz]

Overall, yes, it's not a book I'd heartily recommend. But, is anything
wrong, specifically, with chapters 18 and 19? They seem OK to me.

Don't know, and I'm not checking. I'm already behind on too many
things...

 

[Alex Martelli]

Alex,

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

Availability, simplicity, stability, to name three reasons. The typical
middling-beginning programmer who download a good Python distro is going
to have Tkinter available -- otherwise he or she couldn't be running
IDLE, which is probably the best ways for most Pybeginners to start
playing with Python in a cross-platform way. Putting up a trivial GUI,
which may not LOOK very good, maybe, but still WORKS, is quite simple.
AND, Tkinter isn't going to keep changing under my feet!-)

On the Cookbook site, selecting recipes for the CB's 2nd ed, I noticed
that a vast majority of GUI recipes posted were for Tkinter -- a
_larger_ dominance than at the time the CB's 1st edition was being
prepared. Accordingly, poor old maligned Tkinter is the dominant GUI
toolkit in that chapter of the CB. It would be weird to do otherwise in
the 2nd ed of the Nutshell. If I had space to add a second toolkit,
despite my personal liking for Qt, it would be wx (with PythonCard
coverage, too). But I don't: I gotta choose _one_. Not on the basis of
my personal likes and dislikes (not that I particularly dislike Tkinter,
mind you -- but, even IF I did!), but on the basis of what's gonna help
readers most. And I'm quite convinced that, in late 2004, the answer to
the latter is still: Tkinter.


Alex

 

[Alex Martelli]

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.

Thanks! Very helpful input. Testing surely needs AND deserves more
attention all around, yes.


Alex

 

[Alex Martelli]

What you say is true. However, I didn't think the target audience of
this book was newbies. Python newbies yes, but not programming
newbies. For programming newbies I would recommend the "Learning
Python" book instead.

Sure (or any of the other excellent tutorials, including "Python
Programming for Absolute Beginners"). Such tutorials' coverage of GUI
programming tends to be scarce, though; and moreover, programmers often
come to Python, from other languages, without skills directly applicable
to programming a GUI in Python (as opposed to, say, just painting the
GUI with a tool, as QT Designer or wxGlade may let you do).

Any GUI programming skills that may exist can be Tk-related more often
than one might think... or maybe that's just my own biased observations,
people coming to Python from previous experience with perl or tcl, but
I've known quite a few of those.

The availability argument, however, is a good point.

It has its importance, yes. If you want to replace the de facto Python
standard GUI toolkit with wx, gtk or whatever, having an IDLE-or-better
equivalent using your favourite toolkit, and managing to sneak it into
the std Python distro, would be the way to go;-)


Alex

 

[Russell E. Owen]

Thanks for the advice! What I have now is the best organization I was
able to conceive -- and I have no current ideas on how to enhance it.
Any _suggestions_ will be truly welcome; somehow, I don't see "make it
better" as a _suggestion_... if I _knew_ how to organize it better, I
would, of course.

Fair enough. I was being lazy, but also wanted to be sure the input
would be considered useful before going into details.

Here are some issues for me:

* A mini table of contents for each major section would be really
helpful. List the modules, and (if appropriate) sub-modules with maybe a
one-liner as to what they do, and a page #.

* The discussion of the os module (p171) could especially use such a
TOC. p171 starts with a nice, thorough explanation of os and all it
does, but as a quick reference it is tricky; rather than jumping right
to what I want, I have to get past a discussion of OSError an the errno
module before any os methods are discussed, and then I have to flip
through many pages of stuff to find the right section.

* Please cross-reference using page #s, not just chapter #s or "covered
later in this chapter". For instance the os module text refers one to
"chapter 14" for a discussion of os's handling of processes. Ouch. I
hope that modern writing tools make page # references safe and easy.

* Some of the page breaks are awkward. I know it eats paper to fix it
everywhere, but... for example, it'd help to have the re special
characters table all on one page (or at least on facing pages).

* Exceptions:
- I beg you to include a ONE-PAGE table of exceptions that shows the
inheritance hierarchy via indentation (e.g. like Python Essential
Reference). The detailed info will probably have to follow.

Such a table is a much easier way of figuring out who inherits from who,
and I usually find such a table sufficient (and very efficient) for
picking out which exception to use.

Having the detailed info is much appreciated, but it's a poor substitute
for a quick reference table.

- Some discussion of which standard modules raise errors that inheriit
directly from Exception instead of StandardError would be helpful.

- (nit-pick) The try statement, bottom of p104. The two basic forms are
listed, but a page # for the 2nd form would help jump there.

- Exception objects, p109. Using strings as exceptions would make a nice
footnote instead of cluttering up the main text. They've been deprecated
for a long time.


Also, two content requests:

* please describe the new subprocess module in gory detail and move
discussion of the older modules which it can replace to an appendix or
the back of the same chapter or in some other way keep it from
cluttering up the main text. (I'm sure popen, etc. still has to be
discussed, if only for folks dealing with older code, but subprocess is
clearly the right way to go for new code).

* Please describe numarray instead of Numeric (or both, or discuss
numarray and list some changes from Numeric?)


I'm looking forward to the next edition!

-- Russell

 

[Robert Kern]

Right -- and if I can get the 2nd ed of the Nutshell out within 2005, it
may be too early to say that Numeric has shrunk to the vanishing
point... so I may still need to have both in...

I think that, for people who are approaching numarray/Numeric for the
first time through your book, all they need is a discussion about
numarray and a brief discussion about Numeric's existence, its important
differences from numarray, and why one might use it instead (small array
performance, compatibility with other libraries, etc.). I think that the
core lessons such a person is going to learn from a numarray section of
your book will transfer just fine to Numeric if they are careful. If
they're not careful, a book isn't going to keep them from shooting
themselves in the foot, anyways.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Dave Cook]

the coverage of Twisted and adding just a few things (numarray --

I'd rather have a whole book on Twisted . But I'll take a more extensive
section in PiaN if I can't have it.

Dave Cook

 

[Alex Martelli]

I'd rather have a whole book on Twisted . But I'll take a more extensive
section in PiaN if I can't have it.

I believe one or more books on Twisted are in the works, but I have no
insider info about them, their timing, and so on.


Alex

 

[alecwy]

Discussion of GIL and (in)ability to control thread priority.
Thanks for asking!

 

[Alex Martelli]

Discussion of GIL and (in)ability to control thread priority.
Thanks for asking!

Thanks for answering, but I'm not sure I understand your advice. What
"discussion" of the GIL is needed beyond the 3 lines currently on top of
p. 277? What "discussion" of what _isn't_ there is needed beyond the
information succintly given on p. 279 that "there are no priorities,
groups, destruction or stopping"?


Alex

 

[yaipa]

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

 

[JoeG]

I use your book a lot so another version would be helpful. I know I'll
buy a copy. Heck, I'd pay you money just to have access to the draft
while you write it.

One suggestion I have is to include chapters that expand on test based
development and lazy functions. Maybe you could go into some of the
concepts and methods used in the Zope3 project. That would be useful
to me because I've been reading a lot about it but still can't seem to
grok any of it. It's really hard to learn new concepts from books - no
matter how well written. I usually need to read several different
sources from different authors to get a decent picture.

That gives me an idea for a perfect book. Take a single short subject
- say doctest. Get three or four experts to independently write
chapter. Then combine the chapters into a section. That way I could
buy one book and get the different perspectives I need to really
understand the subject.

You could keep the books small and inexpensive. Twenty bucks and 100
to 200 pages. It would keep the book projects small and specific and
with four people working separately, they could be cranked out quickly.
Combine them all together and you've got a library.

Well anyway, it's probably beyond the scope of your update but I'd like
to see someone do it. Unlike a lot of authors, I can understand most of
what you write.

I've been working with Python for about a year and I still feel like a
beginner. That probably gives me a different perspective than most of
the people you'll hear from. I disagree with your Tkinter vs. wxPython
decision. I tried a number of programs written with Tkinter and really
didn't like the interface. The program I helped develop is Windows
based and I knew that a program with the Tkinter interface would never
work as a cross platform environment. Out existing customers just
wouldn't accept it. I can't see anyone using Tkinter for new mass
market development. If you've already got an application written with
it you might want to continue using it but for new projects, wxPython
seems to have some BIG advantages.

wxPython takes on more of the native platform's interface. I say seems
to because I haven't actually written any code with it.

These are just my opinions. I've been programming for over twenty
years now so I do have some perspective on the market even if I don't
have much expertise with Linux or Python development.

Good luck with your update. Let me know when it's published and I'll
buy a copy.

 

[Michael Bernstein]

Aside from negative indices, I'd also suggest a small (and rather
obvious) example for replacing a substring:

s='spam'
s=s[:1]+'xx'+s[3:]
s 'sxxm'

- Michael