Book Review: Core Python Applications Programming, 3rd Ed.

thatpythonguy writes "Core Python Application Programming is the latest addition to a growing corpus of literature serving a growing number of Python programmers and engineers. This Prentice Hall book of 800+ pages covers some traditional areas and touches upon some new ones. I typically do not spend much time speaking about the author of the books that I review; however, this occasion warrants an exception. And it is not because Wesley Chun used Python over a decade ago to build the address book and spell-checker for Yahoo! Mail nor is it because he holds a minor degree in music from UC Berkeley in classical piano. Rather, it is because he is both an engineer and an instructor. In other words, he was not pulled from his geek duties and asked to become a pseudo-writer; he already does that for his consulting practice, authoring (or co-authoring) several books and articles on Python (including "Python Web Development with Django") as well as starring in his own training video (entitled "Python Fundamentals"). The result of that experience is a writing style that is technically sound, yet accessible." Keep reading for the rest of Ahmed's review. Core Python Applications Programming author Wesley J. Chun pages 888 publisher Prentice Hall rating 8/10 reviewer Ahmed Al-Saadi ISBN 978-0132678209 summary Python application programming for intermediate python engineers The book followed the normal evolutionary path of other books in its class. It started out as the second part of "Core Python Programming" and ended up being split into its own volume in its third edition. The first part became "Core Python Language Fundamentals" which covers the core language. This volume covers the natural successor topics of "now what?" that the first raises: the use of Python in various applications. It is for this reason that the book recommends that the reader be an intermediate Python programmer. I think "intermediate" here refers to anyone who has read an introductory book or followed a tutorial on the core language.

The book covers the two main lines of python development: 2.x and 3.x. Despite the slow adoption of the 3.x line due to its backward incompatibility, there are already popular third-party libraries that have been ported to that line and that occurrence will only increase moving forward. Chun does a very good job balancing the two by providing concurrent examples (i.e., code snippets) in both flavours. He also has numerous references and side notes indicating that certain features/libraries are only available for certain versions of the language.

There are three parts to the book: General Application Topics, Web Development, Supplemental/Experimental. The first includes the usual dosage of general chapters including regular expressions (regex), network programming (including an intro to the Twisted framework), Internet client programming, threading and multi-processing, GUI, and databases (including a taste of NoSQL). It is peculiar that it also includes chapters on Microsoft Office programming and writing Python extensions which are not general in my opinion. It is probably because these two chapters do not fit anywhere else! The second part is probably the core of Chun's own experience as he is a self-described "web guy". He certainly goes into details in that domain covering web clients/servers (yes, he writes a small web server!), general web programming (i.e., CGI and WSGI), the Django framework, cloud computing (mostly Google App Engine; GAE), and web services. Finally, the last part has two chapters on text processing and miscellaneous topics (basically, Jython and Google+). I find the naming of the text processing chapter rather poor given that it is about processing comma-separated values (CSV), JavaScript Object Notation (JSON), and Extensible Markup Language (XML). Arguably, "text processing" is more descriptive of regex, transcoding, and Unicode! Two appendices at the end of the book provide some background and a guide to Python 3.x migration.

Chun spends some time delving into a problem domain in addition to providing the Python solution. For example, he describes the regular expression syntax in detail and spends time explaining the client-server architecture using real-life analogies to drive his points home. His code examples are well-structured, object-oriented solutions that range from the demonstrative to the practical. For example, in the Django chapter, he builds a practical Twitter application that uses third-party libraries and some advanced features. However, do not expect a cookbook-style coverage nor production-ready code from a book of this nature. Do expect many exercises with partial solutions at the end of the book.

I find Chun's approach to be pedagogically sound. His ideas flow logically from one to the next, incrementally building a story-like chain of problems and Python solutions. He highlights architectural patterns that are shared by disparate problem domains (e.g., the event-driven nature of SocketServer and Tkinter), leading to a better understanding of both. However, he does leave out many topics from his coverage for applications in compression, cryptography, and date handling (among others). Maybe he considers these to be ancillary or simple enough to be looked up in Python's own standard library documentation. Also, as a Developer Advocate for Google, it is not surprising to see him cover the GAE in depth. Specifically, I think for anyone who is interested in running Django on the GAE, he can be an excellent (and accessible, by his own admission) resource. Google him (no pun intended!) to see his presentation on "porting" Django applications to the GAE.

Finally, the book is aesthetically type-set and is well-structured. I think that it has a wealth of well-written information that cover key areas of Python application development that will be useful to a broad spectrum of readers.

Ahmed Al-Saadi is a software consultant based in Montreal, Canada. He mainly speaks Python, Erlang, and Objective-C these days.

You can purchase Core Python Applications Programming, 3rd ed from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Re:Why Python?

[gorzek]

The Python module library (which is included, like PHP's) is set up in something resembling a sane, logical system.

PHP just imports every goddamn thing into the default namespace, and tends to have 5 ways to do everything (none of which work similarly, none of which are compatible, none of which do what you want.)

Python typically provides one sane way to do things. I'll grant you that the standard library doesn't include everything PHP does, but there are modules for just about everything and they tend to be painless to install and use.

Not to mention, Python is inherently object-oriented, and PHP is not--PHP's OO is bolted-on and wonky.

The enforced whitespace is really not that big a deal, especially if you are using a decent editor. I never even have to think about it.

Python is quite a well-structured and thought-out language, especially compared to the existential disaster that PHP is.

Re:Why Python?

[gorzek]

Well, I like both, so I won't really argue with you on which is "better."

I'm just not bothered by the whitespace. All languages have their quirks and at least the whitespace one is done for a good reason and doesn't get in my way.

Re:Why Python?

[MarcoAtWork]

Other than Python being inherently object-oriented, I can't fathom any reason for it over Perl for most tasks.

that is a really big 'other than', having had a lot of experience in both perl and python I have to say that as much as you can write workable software in either environment, for large applications I would give python the nod, given its better OO model.

For other tasks it's pretty much a wash between the two IMHO, although when working in a multi-developer environment python's whitespace constraints make the codebase look a lot cleaner (especially if you use things like pep8), and as a previous commenter said once you set things up in your editor of choice it's not that big of a deal.

For emacs this http://pedrokroger.net/2010/07/configuring-emacs-as-a-python-ide-2/ and this http://gabrielelanaro.github.com/emacs-for-python/ would be good starting points.

Re:Why Python?

[fahrbot-bot]

Well, I like both, so I won't really argue with you on which is "better."

I'm just not bothered by the whitespace. All languages have their quirks and at least the whitespace one is done for a good reason and doesn't get in my way.

Agreed. Sometimes there are several appropriate tools for a job and programming languages fall into this category based on many factors, so arguing over which is "better" is often silly.

On the other hand, there is *no* good reason for white space delimited blocks, other than that's the way Python was designed -- especially when mixing tabs and spaces can give one an aneurysm :-) [ Remember kids that X11 converts tabs to spaces during cut/copy and paste...]

All languages have their eccentricities; some are quirks, some are weird, some are just stupid.

Re:Why Python?

[gknoy]

I used to think like Fahrbot-bot: Enforced whitespace is lame, and I'd like the creative freedom to just bang out one line of Perl when necessary. I now love programming in Python. (And felt this way after a week.) After using Emacs to edit lisp for six years, I've become accustomed to "magically" indenting everything to The Correct Place. The language doesn't require it, but the editor makes it trivial, and it's a huge win for code readability. The parens (and braces in other languages) can fade in importance, and become implied when reading a standard code formatting convention.

I tend not to notice the braces/parens in most languages, and rather depend on the notational convention of an indentation style. When code fits the convention, it's easy to read. Python merely enforces a convention which I would already want to use in nearly every case. Yes, I still wish it were easy to (sometimes) write one long line of something like I could in Perl or lisp, but since I rarely ever want to do that even in those languages, I'm willing to live with that. I wouldn't even call it a pain point, except for the fact that it makes it harder to do things like write toy implementations of a function, which I think I've wanted to do twice in three months.

One thing I love about Python, and which Perl doesn't do quite as prettily, is the list comprehension idiom. I find Python's syntactic sugar much easier to read, and it is the idiomatic way of doing a __lot__ of things.

#Perl:
@foo = map{ $_['a'] } @bar
#Python:
foo = [ b.a for b in bar ]

I used to think like Fahrbot-bot: Enforced whitespace is lame, and I'd like the creative freedom to just bang out one line of Perl when necessary. I now love programming in Python. (And felt this way after a week.) After using Emacs to edit lisp for six years, I've become accustomed to "magically" indenting everything to The Correct Place. The language doesn't require it, but the editor makes it trivial, and it's a huge win for code readability. The parens (and braces in other languages) can fade in importance, and become implied when reading a standard code formatting convention.

I tend not to notice the braces/parens in most languages, and rather depend on the notational convention of an indentation style. When code fits the convention, it's easy to read. Python merely enforces a convention which I would already want to use in nearly every case. Yes, I still wish it were easy to (sometimes) write one long line of something like I could in Perl or lisp, but since I rarely ever want to do that even in those languages, I'm willing to live with that. I wouldn't even call it a pain point, except for the fact that it makes it harder to do things like write toy implementations of a function, which I think I've wanted to do twice in three months.

The one thing I miss from Perl is the degree to which regular expressions are embedded in the language, and the ease with which one can use them. It's a little harder with Python, which I find frustrating at times.

One thing I love about Python, and which Perl doesn't do quite as prettily, is the list comprehension idiom. I find Python's syntactic sugar much easier to read, and it is the idiomatic way of doing a __lot__ of things.

#Perl:
@foo = map{ $_['a'] } @bar
#Python:
foo = [ b.a for b in bar ]

If you have been holding off on playing with Python because you love Perl, great. It's still a great language to work with, and the whitespace is not as bad to deal with as you might imagine. My friends use vim with it; I prefer Komodo. There are several other good editors as well.

Re:Why Python?

[Animats]

On the other hand, there is *no* good reason for white space delimited blocks, other than that's the way Python was designed -- especially when mixing tabs and spaces can give one an aneurysm :-) [

That was finally fixed, a decade later that it should have been. Sequences of tabs and spaces which create ambiguity between what you see and what the parser understands are now syntax errors. For example, a line indented with tabs followed by a line indented with spaces is an error.

Re:Core?

[jason.sweet]

They tried "Python Unleashed", but stores kept moving it to the human sexuality section.

Re:Why Python?

[greg1104]

The gap Perl left Python to successfully fill mainly involves shipping a good enough standard module library. Keeping small scoped library enhancement work moving with the Python Enhancement Process minor version after version is the true reason for the language's success.

CPAN has always been a nightmare of bad version control for non-professional Perl programmers, where it's trivially easy to break things if you try and follow what seems the easiest path for installing things. What Perl should have been doing the last 15 years to reduce that problem, to lower the learning curve, is pruning the need for it. Pull more of the best of them into the library of things guaranteed to ship with the language, the less successful ones should die. Let's consider XML as an example. The Perl-XML FAQ starts with "Where can I find reference documentation for the various XML Modules?"; you already lost a chunk of potential Perl developers right there. A quick count on my Debian laptop shows I have 3 packages for that job that aren't in base Perl: libxml-parser-perl, libxml-twig-perl, and libxml-xpathengine-perl. Why? There seems epic "not invented here" going on whenever I get near CPAN, everybody has their own thing.

Given the same job, Python development shook out one XML implementation to ship as part of its standard library, and for everyone to work on, in version 2.0. Then another one was merged into the standard library for 2.5. The other option on my system is a wrapper around libxml2 and libxslt. That's it. The best of the libraries have made their way into the standard library over time, programs can rely on those, and that's good enough for most jobs. This is why Python has kept advancing year after year, while Perl becomes less relevant. You need to know *less* every year to do things in Python, and that's what people look for--a flattening learning curve.

It didn't help that the transition to Perl 6 has taken 12 years so far, making the core language feel dead too. The similarly disruptive Python 3.0 work took 8 years. I think Python managed the backwards compatibility hurdles better too. That's a very subjective thing though, whereas the scope creep leading to nothing useful shipping for Perl 6 yet is a simple fact.

Re:Python is pretty decent, I only have two concer

[nneonneo]

If you're feeling *particularly* devious, you can use a little-known Python feature called "for-else" (also "while-else") which allows you to tag "else" clauses onto for loops. Such a clause executes only if the loop runs to completion 'naturally' (i.e. if no break or exception happens within the loop block).

As a relatively obscure language feature, using it might make your code harder to read. It can help make a multilevel break (chained "else: continue; break" snippets at the end of loops), and reduces the number of flag tests and sentinels you need to do (e.g. a linear search, wherein the "else" case simply contains the if-not-found logic).

There are other alternatives to multi-level break: exceptions can break out of any number of loops until they reach an appropriate handler block, and function returns can always break out of any loop up to the top of the function.

As for switch/case: In C, they were basically a thin wrapper around jump tables for most switches (e.g. enums, small integers, duff's device, etc.). Python's preferred alternatives are key-value dictionaries (hashtables) or if/elif cascades. The former is very easy to setup and manipulate in Python (e.g. {1: 'spam', 2: 'eggs', 3: 'ham'}), unlike in C or C++. The latter is far more flexible than switch/case (e.g. being able to test ranges of values with "A <= x <= B" queries, test for multiple values with "x in (A, B, C)", or do arbitrary tests like "x.isspace()"), while avoiding the complexity of an entirely new language construct.

Finally, goto exists in Python as a third-party module. Go ahead, try it: it really works!

Re:Why Python?

[Compaqt]

The thing with the whitespace is: people don't react well to nannyism.

A lot of people bring up the point: "You would have indented it anyway."

Exactly. Since you would have indented it anyway, what's the point of enforcing it? There are myriad other rules that code shops follow. Do they all have to be hard-coded in the compiler?

Thought experiment: You would have named consonants in upper case anyway. So now the compiler will enforce that.

Like Java-style naming (thisIsAFunctionName)? The compiler will enforce it. Prefer this_is_a_function_name? Sorry, underscores not allowed.

What Python fans (meaning those who think Python is 100.00% wonderful, instead of 98% wonderful like the rest of us think) miss is: What problem is it that hardcoding a formatting rule in the compiler solves?

Re:Why Python?

[Terrasque]

Python also has no idea of public and private in its classes. The closest it comes is the double-underscore prefix which mangles names, but not to the point that clashes are impossible. Python has the trite saying that "we are all adults" (or something similar), implying that we just shouldn't poke around at things that start with an underscore. However, the lack of public/private essentially means that a large advantage of classes (the ability to keep a stable public API while completely changing how the backend works) is removed: if I create a subclass, since there's no such thing as private, I just have to cross my fingers and hope the superclass author doesn't choose names that clash with mine. Basically, if you're subclassing, you have namespace global to all classes.

First of all, python have good support for later adding setters / getters if needed.

And for public API, if you poke around with _variables and __variables in someone else's class, you should EXPECT things to go to hell in the future. _ and __ basically says "this is not meant for you. Any usage is on your head" - it's still there, so you can if you have to. But you shouldn't, and you're making a deliberate choice when you do. That's what the "we're adults" saying points out. You're not a kid, so we won't lock away things. It's your responsibility to use it properly.

And for the third, if you're subclassing and want to make sure your variables don't clash, use __mynewmodulename_variable format. Simple :)