Programming Python
Mark Lulz
Programming Python is the more practical of the Learning Python-Programming Python pair. In all, I like this book better. I'm more of a practical programmer than theoretical one. As a Perl fan, I hate to see the oft-repeated attitude that Python is a "better Perl". Other than that, I have no problem. I am somewhat disappointed to discover that the thick 1500 pages tome does not cover PyGame. It does get a mention, but come on. Don't you think that if you don't have a space to cover that, at least reference some good books on it? I'm rather disappointed. Granted, the main purpose of the book is to write a clean, portable python programs, and in that mission, it succeeds admirably. But the lack of other resources cited remains a rather curious omission that would have made the book even more complete.
I also think that as good as it is, the book fails to convey Python's strength. Take this example from the clock (Ch 11, p748):
- def point (tick, range, radius):
- angle = tick * (360.0 / range)
- radiansPerDegree = math.pi / 180
- pointX = int( round( radius * math.sin(angle * radiansPerDegree) ))
- pointY = int( round( radius * math.cos(angle * radiansPerDegree) ))
- return (pointX, pointY)
Reading the code makes it obvious that this is just a way to return a point, given angle and distance. In other words, polar coordinates. There are several marks, that I want to address.
- Why the parenthesis in (360.0 / range)? Precision should be no problem. The only reason that I can think of is variable types. I mark this as a drawback of strongly typed languages. The parenthesis should be optional.
- radiansPerDegree? Some languages provides that as a function. Why do you have to built your own?
- int( round( ? Come on. In any other language, it's either int() or round(). Definitely not both!
- math.sin(), math.cos(). Do you seriously prefer this to sin(), cos()?
And that's just the language. I suppose, if I'm feeling mischievious, I can point out that radiansPerDegree is completely internalized, and thus unnecessary complication. Just because the function takes radians, does not mean you have to convert degrees to radians. Like so:
- angle = math.pi * 2 * tick / range
You may put any necessary parenthesis where you want. If simple is better than complex, then the text code doesn't show. What's the matter? Can't think in radians? Don't you think that as a professional programmer, you should learn it? No computer language is so good that you can be sloppy!
And if I really nitpick, I guess I can complain about associating X with sin, and Y with cos, instead of the "proper" way X with cos, Y with sin. But I won't. ;)
And here's another thing, later in the book (p. 761):
- class PPClockBig(PhotoClockConfig):
- picture, bg, fg = gifdir + 'ora-pp.gif', 'navy', 'green'
- class LP4EClock(GilliganClock):
- size = 700
- picture = gifdir + 'ora-lp4e.gif'
- bg = 'navy'
and so on...
I counted 9 such classes. People have pointed out to me that Python is so powerful that it can take such flexible class arrangements. I agree that the language is powerful in order to take that. However, I'd rather see it in tabular form. A straight array will be simpler, cleaner, and clearer. Plus the advantage of loading it from file, so that you don't have to change the code just because you want a new background color. BTW, Perl can trivially do it via HereString, while retaining simplicity and clarity.
The book ends with a bad joke:
"But how will I know why Python is better than Perl?"
"You will know. When your code you try to read six months from now."
I think that joke is in poor taste. You're trying too hard to position "Python as the better Perl". My response?
"I get it. Your brain is spaghetti. However, instead of straightening your brain and learn how to code properly, you simply blame your tool. What kind of a workman, are you?"
I can still recommend the book, but it's not as good as Learning Python. Little distractionary things pepper the book, and I do not enjoy it as much.
No comments:
Post a Comment