The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

import-bot (20211) [Avatar] Offline
#1
[Originally posted by sabi]

Hi,

I'd just like to echo other people's comments re: the fact that the book
really needed more proofreading, even ignoring the problems with the
interactive examples. I could have just spent a day reading it (having never
used Python before) and come up with at least 100 typographical and content
errors. I don't think my talents are that unique either - I'm a programmer
not an editor, dammit smilie I really liked the organization of the book and the
tone, though, it was very easy to read and taught me a lot in a short time.

Anyway... I have read through most of the book and am now kicking myself that
I didn't make a note of all the errors, trusting that the errata page was
complete. A few things I do remember noticing:

- page 286, this example is really poorly written. I do know Java, and I know
that importing java.lang.<anything> is redundant, naming instance variables
with capital letters (e.g. Account) is nonstandard and confusing, and the
manipulations with the StringBuffer in toString() seem very strangely put
together. I would write it more simply as:

public String toString() {
return Account + " " + Amount + " " + Type;
}

The Java compiler does the appropriate transformations to StringBuffers
(something like return new StringBuffer().append(Account).append("
")...toString()) itself.

- page 271, "assuming the name of the module you are creating is 'xx'." This
looks suspiciously like a placeholder to me. Looks like it should be
'example1' instead. There's another example on page 271 in the comment at the
bottom of the page: "PyArg_ParseTuple will place an exception message into a
standard global variable xxx".

- page 298, "three principle roles" should be "three principal roles".
import-bot (20211) [Avatar] Offline
#2
Re: Errata and comments
[Originally posted by daryl harms]


>
> - page 286, this example is really poorly written. I do know Java, and I know
> that importing java.lang.<anything> is redundant, naming instance variables
> with capital letters (e.g. Account) is nonstandard and confusing, and the
> manipulations with the StringBuffer in toString() seem very strangely put
> together. I would write it more simply as:
>
> public String toString() {
> return Account + " " + Amount + " " + Type;
> }
>
> The Java compiler does the appropriate transformations to StringBuffers
> (something like return new StringBuffer().append(Account).append("
> "smilie...toString()) itself.
>

<Response from Kirby Angell (the author of this section)>:

Importing java.lang.<anything> may be redundant as far as the compiler goes,
but for human readers it does make it obvious what classes the following
code will be using. I generally write my programs so humans can read them,
not for the benefit of the compiler. For instance, in my production Java
applications created in the last year or so you will rarely see "import
package.subpackage.*". Instead I import each class individually just to
make it clear to the reader what the class will be doing. As a side benefit
(except for java.lang) the compiler lets me know when I have used a new
class in my class's implementation. On more than one occasion I have
decided to reimplement a class due to this feedback from the compiler

This falls into the same area as the naming of instance variables. When
Java is 10 or 15 years old there will probably be some sort of generally
accepted way of doing things; frankly I've yet to see that in the C++ world
but there is always hope. I wouldn't attempt to hold up the Java examples
in the book as good or bad examples of Java programming anyway. There are
many other things missing from the classes in my opinion to make them good
Java classes. The Java examples are there to illustrate points on
integrating JPython and Java; not as examples of good or standard Java
programming.

And finally, mia culpa on the StringBuffers. I don't like the StringBuffer
class in general and really do not see the reason for separate String and
StringBuffer classes. Since I don't use StringBuffers very often, I didn't
examine the syntax adequately to determine their best use. You do say that
"The Java compiler does the appropriate transformations" which does bother
me a little. If the Java compiler is doing it behind the scenes then it may
not be obvious to the human reader of the code what is happening. As an
example, you and I may know that in the expression "4 * 5 + 1" that the
result will be 21 not 24 because Java will perform the multiplication first.
However I would always write the expression in my code as "(4 * 5) + 1" to
remove any doubt from the reader's mind as to what is going on.

A conversation for another forum is why Java trusts itself to overload the +
operator and do the StringBuffer operations, but the language spec will not
allow me to add similar behavior to my classes. All that said, your version
of toString is still much cleaner looking.

<End response from Kirby Angell>


> - page 271, "assuming the name of the module you are creating is 'xx'." This
> looks suspiciously like a placeholder to me. Looks like it should be
> 'example1' instead. There's another example on page 271 in the comment at the
> bottom of the page: "PyArg_ParseTuple will place an exception message into a
> standard global variable xxx".
>

These are actually correct as written. For example the "make_static" script is:

---------------------------
#! /bin/sh

# This script tests and demonstrates the mechanism for building a
# static Python binary with an additional extension module using the
# generic Makefile.pre.in from the Misc directory.

./make_clean

cp ../../Misc/Makefile.pre.in .
cp ../../Modules/xxmodule.c .
echo xx xxmodule.c >Setup.in

make -f Makefile.pre.in boot
make Makefile
make static
---------------------------

If you are planning on extending Python, be sure to look at the new version of
Guido's "Extending and Embedding the Python Interpreter" document at:
http://www.python.org/doc/current/ext/ext.html

He put out a significantly enhanced version of this last week (March 22). It
will be the old version that will have been downloaded and installed on your
local machine with the standard 1.5.2 release of Python.

> - page 298, "three principle roles" should be "three principal roles".

Yes, definitely. Thanks for your feedback, Nicholas.