Book Review: Core Python Applications Programming, 3rd Ed. 65
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.
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.| 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 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.
Re:Why Python? (Score:5, Informative)
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: (Score:2, Insightful)
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.
Perhaps, but it still stupid, unnecessary and potentially problematic. Other than Python being inherently object-oriented, I can't fathom any reason for it over Perl for most tasks. (Not trying to flame/troll, I'm just saying that's my opinion w/25+ years of experience.)
Re:Why Python? (Score:4, Interesting)
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: (Score:3)
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
Re: (Score:3)
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: (Score:2)
On the other hand, there is *no* good reason for white space delimited blocks
On the contrary there is a very good reason to have indent delimited blocks sans the visual clutter of braces etc.: Readability counts.
especially when mixing tabs and spaces can give one an aneurysm :-)
Which is why you should 1.) Follow the advice in the Style Guide (aka PEP 8), "Never mix tabs and spaces ... For new projects, spaces-only are strongly recommended over tabs.." And 2.) set up your editor to make it so. Having
Re: (Score:3)
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
Re: (Score:2)
...and as a previous commenter said once you set things up in your editor of choice it's not that big of a deal.
Sure, and I'm a heavy Emacs user -- and also LISP programmer, to respond to another post -- (from way back), but I and others routinely (nay, daily) also use several other editors, sometimes on the same code, depending on when and where we have to edit it. We also use several other languages daily - and (w/2 others) maintain about 500k lines of code in about 10 different languages on Solaris/Linux/Windows (none of which are white-space delimited) - so learning and using another language isn't the issue.
Re: (Score:2)
Re: (Score:3)
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 import
Re: (Score:2)
Bloody hell -- double pasting what I meant to edit. I'm very sorry about that. Short version:
- I use whitespace conventions to read code more easily, so enforcing one is no different from using Emacs or Eclipse to autoformat everything. I find Python code indentation very similar to Lisp-y indentation.
- I miss Perl's easy regex integration.
- I miss being able to write one-liners on the command line, or toy implementations in the REPL. In practice, I nearly never need to do this.
- List comprehensions (and d
Re: (Score:3)
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
Re: (Score:2)
Since you would have indented it anyway, what's the point of enforcing it?
Let me turn that around:
Since you would have indented it anyway, what's the point of braces?
Also, when you're pushing enter at the end of the line anyway, what's the point of ; ? Yet, almost no one complains about that missing for some reason..
It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away
Why have something that isn't needed? Why say the same thing twice? It'll just add to what can go wrong.
Inconsistence between bracing and indentation leads to confusion. Confusion leads to anger. Anger leads to hate. Hate leads to suffering.
*sad Yoda face*
Re: (Score:2)
Exactly. It sounds like a really big deal at first, but in practice (and believe me, I am still new to Python) it no longer seems like a big deal. There's so much other good, expressive stuff in well-written python that minor annoyances are less critical, and the "whitespace rules" end up being no different than having an agreed-upon coding style (KNR, etc) in your organization. To be fair, this is likely because I happen to work with a codebase of what looks like very neatly written Python, and also prefer
Re: (Score:1)
I don't even consider perl to be a first class language it is a nasty hack that got completely out of control.
Show me how you define a function call that takes parameters? Never mind I know how it is done in perl, just saying with my 25 years of experience.
typing curly braces, begin, end etc is just unnecessary cruft to type simply to satisfy the compiler.
Re: (Score:3)
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
Re: (Score:2)
it still stupid
why?
unnecessary
you have to delimit code blocks somehow, if it weren't this it would be curly braces or something else
potentially problematic
But not problematic in practice.
Re: (Score:1)
Python's OO isn't horrible, but it's not great.
There are two types of classes, old-style and new-style. That alone is pretty annoying, since if you're subclassing an old-style class (new classes should, of course, all be new-style), you can't use "super" (not that "super" is well-designed, either). So all Python's included classes have been updated to be new-style, right? No, of course not!
Python also ha
Re: (Score:3)
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 [thegreenplace.net] 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 lo
Re: (Score:1)
The Python module library (which is included, like PHP's) is set up in something resembling a sane, logical system.
This. Coming from a Java background, I had the opportunity to begin and deploying custom applications over a year ago. Since then, I have found the language pragmatic and straight-to-the-point i.e. Pythonic. You should see how Java developer's head spin when I tell them I got a prototyped RESTful Web Service interacting with our legacy system in two days.... TWO DAYS! This is from someone who considers himself a basement coder versus all these J2EE developer types Thank you Flask! Plain and simple, Py
Re: (Score:2)
Really? What a slacker, I know it does not take two days. I understand though, 5 minutes per day and the rest of the time to surf Slashdot.
On day two the java dev is still trying to figure out why his class path is screwed.
Re: (Score:1)
Re: (Score:2)
I am myself familiar with PHP but not Python. What's so good about Python and why should one choose to use it? Let's take for example PHP's comprehensive library that is usable without any downloads and external includes. It's one of the things I love about PHP. Python seems to miss that.
That's both good and bad thing. PHP doesn't really have any solid library thinking, it just has random functions thrown together and glued across with some duct tape and spit. Since changes to core language basically alter how the entire language works, it gets really f-ing annoying to maintain your codebase between versions. Meaning you have to rewrite alot of code.
The external includes allow you to build compiled projects, which can be delivered without source code.
Not sure if you can do something lik
Re: (Score:2)
>Another thing I don't like about Python is the use of TABS and white space as code block separators. Really? Why??
Just because the creator happened to like that and decided to enforce it on the rest of the world.
>I'm sure Python can be great language but the style and some parts of it really put me away from it.
It is a great language, for the most part.
Here's the weird stuff: You already mentioned tabs. The stock answer is "use an editor designed for Python." Erm, what? Why should I have to use an ed
Why an editor? (Score:1)
Re: (Score:1)
IMHO, this editor thing is very much a non-issue. Every remotely sane (and wishing to retain that state) Python programmer I know of uses spaces, and ONLY spaces. And they make sure to set their editors to treat hitting tab button as a shortcut to insert a set number of spaces. And hitting backspace in front of at least the same amount of spaces to chuck away that same amount of spaces. And if your editor can't handle stuff like tab/spaces replacement, you really should look for alternative editor anyways.
Re: (Score:2)
Here's the weird stuff: You already mentioned tabs. The stock answer is "use an editor designed for Python." Erm, what? Why should I have to use an editor specifically for one language? For any other language, I can use any editor or none (count gedit as none).
Not easily. Writing decent code in any language gets a lot harder if you don't have help with indentation. You'll make mistakes and your coworkers will waste time reindenting it.
And when you decide to play with Python in a serious way, you now get to go editor-hunting, downloading, installing and trying them out, figuring out their idiosyncrasies.
That's when it pays off to already have invested in an editor which is everywhere and supports everything, like Emacs or Vim.
Re: (Score:2)
Another thing I don't like about Python is the use of TABS and white space as code block separators. Really? Why??
You don't have to use tabs, you can indent your blocks with any number of spaces as well -- so long as you are consistent within each particular scope.
As to why, easy -- it allows Python to reclaim two high value delimiters ({,}) for another function (dictionaries).
Re: (Score:2)
Eric S. Raymond's answer [linuxjournal.com]
As he (and many other comments here explain), most of the "issues" people think Python have (like the significant whitespace part) aren't even noticeable after a short while.
And as he points out, it's a language that's well designed and easy to both learn and work with.
IMHO, with it's modular approach it's very structured and self-similar. And the duck typing approach makes the modularity even stronger.
Re: (Score:1)
Python Web Development with Django (Score:2)
Re: (Score:2)
Core? (Score:2)
How is it core Python programming when it's 800 pages?
Another case of publishers coming up with one keyword and then using it for every single book they put out.
-Unleashed
-In 24 hours
-In 30 days
-Pragmatic
Re:Core? (Score:4, Funny)
sounds like a good "next step" book (Score:2)
Especially this part, "...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."
I'm assuming the chapters are written so that you can "jump-in" without having to follow up the preceding material. I only question this point because the reviewer states: "His ideas flow logically from one to the next, incrementally building a story-like chain of problems and Python
Re: (Score:1)
...
I'm assuming the chapters are written so that you can "jump-in" without having to follow up the preceding material. I only question this point because the reviewer states: "His ideas flow logically from one to the next, incrementally building a story-like chain of problems and Python solutions."
Your assumption is correct. Naturally, in this class of literature, you expect the ability to random-access what you need. The logical flow refers to cohesive units of text that mostly span one chapter.
A "Core" of 800+ Pages? (Score:1)
I'll wait for the Cliff's Notes version, thank you.
Python is pretty decent, I only have two concerns (Score:1)
The only two things that really bother me about python are:
1) after 25 years they still refuse to add a switch/case statement (makes writing FSMs harder)
2) there is no gaurantee that a destructor is ever called, thus you cannot implement a RAII pattern with objects
As for white-space delimiting, don't knock it till you try it. Just use a good editor (eg emacs, or other smart editor). Once you get used to it, it's actually very easy on the eyes sans having extra delimiters (curly braces, semicolons, etc.) and
Re: (Score:2)
The only two things that really bother me about python are:
1) after 25 years they still refuse to add a switch/case statement (makes writing FSMs harder)
2) there is no gaurantee that a destructor is ever called, thus you cannot implement a RAII pattern with objects
Switch/case has always been a bit of a funky construct. LISP's cond was just a general form of if/then/else'. C's switch was pretty tied to C's eq style equality (and was a fun hotspot for compiler writers.) C++'s switch is just an artifact from C that must ignore C++'s attempts to generalize equality. Fortran's computed goto is best described as "interesting." I'm not sure what Python could provide in this space that would be a significant benefit.
RAII is also a bit funky. The best garbage collector is oft
Re: (Score:1)
Well, why not simply decouple the two operations--they already did so for instantiation: __new__() and __init__(), why not separate the converse with __deinit__() and __del__()?
Then when you call "del foo" in code, you are invoking __deinit__() destruction, freeing resources, etc, but leaving the GC free to call __del__() when or if it sees fit.
That's the real pattern RAII wants anyways--tying resources to the semantically-meaningful life of the object, not the life of the object in memory (since that is no
Re: (Score:2)
Well, why not simply decouple the two operations--they already did so for instantiation: __new__() and __init__(), why not separate the converse with __deinit__() and __del__()?
Then when you call "del foo" in code, you are invoking __deinit__() destruction, freeing resources, etc, but leaving the GC free to call __del__() when or if it sees fit.
That's the real pattern RAII wants anyways--tying resources to the semantically-meaningful life of the object, not the life of the object in memory (since that is non-deterministic/varies by GC algorithm).
You might be right. I've never liked Python''s new/init stuff.
As for switch/case, either add that, or goto. There *are* use cases where it makes coding cleaner/easier to read--which is one of the underlying points to python, isn't it?
A use case, or even infinite use cases, does not mean it is a good idea. Even a use case in which some snippet is objectively easy to read. This is basic language design. If you add a new entity to your language, you and your users have to understand what it is.
Take, for example, the target (label) of your proposed goto statement. Is it a marker in a block of text? If so, how does it interact with try/catch/finally? Is it a first class object? Is
Re: (Score:3)
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 th
Re: (Score:1)
1) A switch in python is implemented using a dictionary
2) RAII is done through context managers ( http://docs.python.org/reference/datamodel.html#context-managers )
When Python lets me... (Score:2)
lets me choose my own block delimiter I will consider it, until then it sucks ditch water and is not worthy of even the most banal task.
Re: (Score:2)
python lets you use any delimiter you would like, take the following example code for instance.
#{
print "hello I am a moron and like to type cruft"
#}
Re: (Score:1)
he wrote a small web server!.
That's probably an example of what you can find in the book, it is in the 2nd edition of Core Python Programming.