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

[Dave Reed]

On Wednesday 29 December 2004 18:01, Alex Martelli wrote:

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




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

<snip>

This discussion is making me think what would be really nice is an
advanced Python book that discusses many of the topics mentioned in
this message and earlier messages in the thread. I'd rather see an
in-depth advanced book than light coverage of the topics added to a
Nutshell book. I own at least 8 or 9 Python books now and the 3 that
I keep within arms reach of the computer are Nutshell, Cookbook, and
Python Essential Reference.

Dave

Dave

 

[Alex Martelli]

This discussion is making me think what would be really nice is an
advanced Python book that discusses many of the topics mentioned in
this message and earlier messages in the thread. I'd rather see an
in-depth advanced book than light coverage of the topics added to a
Nutshell book. I own at least 8 or 9 Python books now and the 3 that
I keep within arms reach of the computer are Nutshell, Cookbook, and
Python Essential Reference.

Yes, good point... I _do_ plan another book after I'm done with the 2nd
ed Nutshell, though ti will mostly be about Design Patterns and
development methods so may not meet your exact desires...


Alex

 

[Mariano Draghi]

Alex Martelli escribió:

Yes, good point... I _do_ plan another book after I'm done with the 2nd
ed Nutshell, though ti will mostly be about Design Patterns and
development methods so may not meet your exact desires...

Now I'm anxious! *that* is the book I'm waiting for
I think the Python community really needs such a book; you have plenty
of books and articles and papers and resources on-line with (almost) all
the bits & pieces. But I really miss a book that focuses in the
"Pythonic way" of project management, design patterns, development
cycles, QA... something targeted to the enterprise.

I think that somehow Python's "J2EE" equivalent is already out there
(sort of...), if you have time to look for the bits, and if you manage
to glue them together. A good book with a higher level approach, focused
in design, would be an invaluable help in that proccess.

 

[matiu]

I enjoyed the first edition.

Please include:

vpython.org, twisted and pygame

and if you'll consider a gui toolkit do pygtk, we use it to develop and
deploy on both windows and linux, with glade gui designer and libglade
(loads the glade xml files in runtime). It's much easier to use than wx
and looks nicer than tk

Thanks for reading.

 

[Nick Coghlan]

I think that somehow Python's "J2EE" equivalent is already out there
(sort of...),

I think it's called PEAK. . .

Cheers,
Nick.

 

[Nick Coghlan]

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

While Tkinter is the GUI toolkit shipped *with* Python, then that's the correct
toolkit for Alex to cover in PiaN. Mentioning other toolkits (and providing
references for additional information, including books if they're available)
seems like the most reasonable alternative.

Now, if we could just switch to wxPython and Boa Constructor for Py3K. . .

Cheers,
Nick.
Sorry Kurt!

 

[Gregor Horvath]

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.

I was/am a python newbie beginning to learn python with this excellent book.
I think it would have been much easier if there were more comparisions
of features to other mainstream languages which one likely already knows
(C, VB, Java ...)

I liked the following Java book especially because of those comparisions:

http://www.amazon.de/exec/obidos/AS...997/ref=sr_8_xs_ap_i1_xgl/302-1345611-4845666

The included comparisions helped me to get into the Java language more
quickly.

 

[Dennis Lee Bieber]

I was/am a python newbie beginning to learn python with this excellent book.
I think it would have been much easier if there were more comparisions
of features to other mainstream languages which one likely already knows
(C, VB, Java ...)

But what language do you pick... Given my background, the "best"
comparison languages would have been FORTRAN 77, Ada, (A)Rexx, and, just
to be perverse, COBOL 74.

Out of that list, only Rexx is a scripting language (and by
nature of its ADDRESS statement capability, it is more of a scripting
language than Python). Only Ada has any real object capability. COBOL
and FORTRAN are statically typed. And none of them have the somewhat
unique reversal of variable and content that Python is based on (by this
I refer to the classical "mail sorting box" view of variables -- a
variable name identifies one, and only one, box, and assignment copies
the contents/value of the right hand side to the identified box -- vs
Python's "post-it notes" view where the contents/value only exists in
one box, and "notes" with the variable name are "stuck" to the
appropriate box; when a box has no more "notes" the contents are garbage
collected).

However, this is a moot point... The subject in question is an
O'Reilly "Nutshell" book -- these books tend to focus on short but
detailed coverage specific to the subject of the book. IE, they are not
teaching books, but closer to focused reference manuals covering the
more obscure features of the subject.

I've got eight Nutshell books on my shelf. Only one, as I
recall, makes any nod to other languages -- and that is in the history
of VB/VBA section, where mention may be made of precursors such as
WordBASIC.

The included comparisions helped me to get into the Java language more
quickly.

After a short amount of time with a multitude of languages, not
even in-depth, one tends to learn how to ignore specifics of syntax to
get to the core concept behind the syntax. Classes, functions, etc. are
similar in all languages when one thinks only of the application
functionality that is to be implemented.

--

 

[Pekka Niiranen]

Well,

I have not read the previous version, but
I would like to see an example how to redirect console messages
from scripts to Tk windows in UTF-8/16 for debugging purposes.
(I hate those "ordinal not in range(128)" messages)
This involves setting font (Arial MS Unicode), scrollbar and
"Continue" -button (allows script to continue execution).
It could be called "Unicode aware scrollable message box in Tk"

-pekka-

 

[JanC]

JoeG schreef:

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.

Robin Dunn is writing a wxPython book:
<http://article.gmane.org/gmane.comp.python.wxpython/17535>

 

[Bryan]

While Tkinter is the GUI toolkit shipped *with* Python, then that's the
correct toolkit for Alex to cover in PiaN. Mentioning other toolkits
(and providing references for additional information, including books if
they're available) seems like the most reasonable alternative.

Now, if we could just switch to wxPython and Boa Constructor for Py3K. . .

Cheers,
Nick.
Sorry Kurt!

i would prefer PiaN not to cover any gui toolkits, and instead use that space
for more core funcionality.

thanks,

bryan

 

[kery]

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,

Good sub-point, thanks.


Alex

Any schedule for publication of 2nd Ed? I just bought 1st Ed.

 

[Steven Chan]

I completely agree. I'm also waiting for an advanced Python/project
management book that helps folks out with large-scale projects.

And, for the 2nd edition, may I suggest:
- coverage of OptionParser module, which is more advanced than the
getopt module that you discuss on page 141.
- better Mac OS X application building coverage. Tell us how to build
double-clickable applications.

I wish I could ask for wxPython coverage (the whole chapter on tkinter
is useless to me), but I won't start a flame war here.

:: steve ::

 

[Alex Martelli]

Any schedule for publication of 2nd Ed? I just bought 1st Ed.

The 2nd edition Python Cookbook appears to be on-track for PyCon (late
March) for the very first ink-on-paper -- probably April in bookstores.

The 2nd edition Python in a Nutshell is more doubtful, being just
started and all that -- OSCON is a possible target, but it's way too
early to say if I'll manage to hit it.

In both cases, the 2nd ed is meant to focus on versions 2.3 and 2.4 of
Python, while the 1st ed covered all versions up to 2.2 included. So,
if you're still interested in using Python 2.2 or older versions, you
may want to stock up on 1st editions of Cookbook and Nutshell; if you're
only interested in 2.3 and following versions, in the case of the
Cookbook waiting 2-3 months for the 2nd ed may be worth it, while, in
the case of the Nutshell, I would definitely not recommend a far longer
and more uncertain waiting period of 7 months or more. Moreover, the
changes in the Nutshell will be less than those in the Cookbook were:
the Cookbook has changed way more than 50% of its contents, the Nutshell
will change substantially less (according to current plans: I'll be able
to give more precise information later this year).


Alex

 

[Alex Martelli]

I completely agree. I'm also waiting for an advanced Python/project
management book that helps folks out with large-scale projects.

I won't schedule that project until the Nutshell 2nd ed is substantially
done... and I'm not _promising_ I'll schedule it right afterwards;-).

And, for the 2nd edition, may I suggest:
- coverage of OptionParser module, which is more advanced than the
getopt module that you discuss on page 141.

I assume you mean optparse -- that's the module; OptionParser is a class
within that module. Yep, covering that is in the plan.

- better Mac OS X application building coverage. Tell us how to build
double-clickable applications.

Python in a Nutshell is a book about *cross-platform* Python. There is
practically no *WINDOWS*-specific coverage -- 80% of the market or
whatever -- it would be absurd if there was platform-specific coverage
for a (wonderful) system that has less than 1/10th as much volume (and
much as I may be rooting for the mac mini to revolutionize the market, I
suspect it will only make a relatively small, incremental difference).

I *WISH* I could write a book about Python on the Mac -- ever since I
got my iBook, over a year ago, it's been my love and joy, and as soon as
I had to change a desktop machine I got myself a dual processor G5
PowerMac too. However, when I proposed that idea to O'Reilly, their
reaction was a firm no -- it's too narrow a market, they think (and,
being the premier publisher for both the Mac AND Python, they should
know, if anybody does).

I don't know if this perception of O'Reilly can be changed. If it ever
does change, I sure hope they'll call me first, to do that book...!!!

I wish I could ask for wxPython coverage (the whole chapter on tkinter
is useless to me), but I won't start a flame war here.

As long as Tkinter is distributed with standard Python and not
deprecated, it's unlikely that a reference work about Python can just
quietly ignore it. If standard Python changed in this respect, I would
of course take that into account in the next following edition!-)


Alex