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

Why Python?

[HearVoic]

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.

Another thing I don't like about Python is the use of TABS and white space as code block separators. Really? Why??

I'm sure Python can be great language but the style and some parts of it really put me away from it. This book might be well-structured, but IMHO Python itself isn't.

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?

[Anonymous Coward]

Must be trolling. This comment makes my brain hurt.

Re:Why Python?

[fahrbot-bot]

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?

[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?

[Keruo]

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 like this with PHP using hiphop etc.

Another thing I don't like about Python is the use of TABS and white space as code block separators. Really? Why?? I'm sure Python can be great language but the style and some parts of it really put me away from it. This book might be well-structured, but IMHO Python itself isn't.

Block separators is something I really hate with python aswell. It becomes hard to read if you're outside IDE.

Re:Why Python?

[Compaqt]

>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 editor specifically for one language? For any other language, I can use any editor or none (count gedit as none).

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.

Second big one: "self". For those not in the know, that's the pointer to the current object. Like this in C++. Unlike most object-oriented languages, whose claim to fame is that they handle the object-orientation for you (instead of having to hack it out in C like with gobject or GTK programming), Python asks you to manually pass the current object pointer around.

This is especially surprising because Python is positioned as a programming language for beginners and kids.

Why do you need to worry about such low-level details? Not to mention the extra typing. What happened to succinctness as a virtue?

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?

[Anonymous Coward]

Some of us also find PHP (and doubly, PERL) syntactically confusing. I have a hard time reading PERL and quickly groking what's going on. To be fair, it's been 10 years since I really worked in PERL.

So as this question always gets answered, to each their own. I happen to prefer Python. There's lots of activity around it right now too, which makes it easier to get help (which I frequently need).

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?

[Anonymous Coward]

According to Wikipedia, Python has been around since 1991. 2012-1991 25.
Troll harder bro.

Re:Why Python?

[Anonymous Coward]

Because readability enhances comprehension.

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?

[gknoy]

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 dict comprehensions) are the bees' knees.

Give Python a shot if you have been avoiding it because "enforced whitespace is lame". It's easier to get over than you think.

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:Why Python?

[codepunk]

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:Why Python?

[fahrbot-bot]

...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. Personally, it's more that I dislike things that are stupid for no good reason, such as are white-space delimited blocks (as I mentioned before).

But, to each their own, enjoy...

Re:Why Python?

[Anonymous Coward]

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

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

I'd certainly take Python over PHP, because PHP is an abomination. Python, though, is a language I would just consider mediocre. It's got the right idea for its intended domain, but trips and falls a lot while trying to implement it.

Re:Why Python?

[Anonymous Coward]

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

you can run python snippets with python -c '...'
separating lines with ; works but sometimes newlines are necessary like in case of if else, besides multiline string is no problem in shell.

Re:Why Python?

[tommituura]

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.

Voila. The problem... goes away. Really. It just does. There is no spoon - I mean, problem.

FWIW: I, too, mainly use gedit and vim to write Python and after setting them to insert spaces instead of tabs I have hard time seeing why everyone is making up such a fuss about this "issue".

And if I'm understanding your second point correctly, I have hard time seeing having to include self in the methods' parameters lists as a big problem either. What is that... 5 or 6 additional characters per method definition?

Re:Why Python?

[mastashake57]

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, Python rocks and it rocks hard. I'm buying this book ASAP.

Re:Why Python?

[codepunk]

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:Why Python?

[mastashake57]

Shhh! Why you blowing my cover!?!?! I gotta bill for all that time, dude, and still look better than the Java guys. You're violating Python Bro-code!

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:Why Python?

[Wrath0fb0b]

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:Why Python?

[Anonymous Coward]

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.

Using the '\' character on the end of a line signals the interpreter that a expression/statement is continued on the following line.

Re:Why Python?

[aztracker1]

Well, most developers indent their nested blocks/closures anyhow, so having a language that just reacts that way, kind of make sense. I'm not a big fan, but I do get the logic behind it.

Re:Why Python?

[Anonymous Coward]

In Python I can just type in the pseudocode I have been using for decades, and it works.

Off topic: when I view the /. homepage, I'm logged in. As soon as I click on a story I become an Anonymous Coward. Has anybody else experienced this bug? I'm using FireFox (with Adblock, noscript (but /. has permission) & Better Privacy on Xubuntu).

Re:Why Python?

[Anonymous Coward]

Why do you keep saying "for no good reason", like it was a whim? There IS a good reason, which is that people learning the language have to learn to indent their code sensibly (i.e. the code looks right when it's written right, and has a minimum of syntactic fluff). The appearance of the code to readers was considered to be important enough to force certain styles. In fact, I would suggest there is no good reason for someone to need to write:
if condition { doThing(), doAnotherThing() }

You obviously don't agree with the choice, but that doesn't mean it wasn't carefully made.

Re:Why Python?

[Anonymous Coward]

Regarding the indentation for blocks, consider:

You indent your code already, right? Sure, who doesn't.

Why do you do that? If human beings were good at picking out matched braces, we wouldn't need to indent. So the indentation must help us pick out blocks. (And, indeed, spacing is one of the half-dozen-or-so ways the eye identifies patterns.)

Then why are you typing braces? You already have something that tells you what's part of a block: the indentation. Braces are completely superfluous, except that a computer would be confused without them. You're doing the same thing twice: once to keep humans happy, once to keep computers happy. That's ridiculous. Why not get rid of one? We can change how a computer sees but not how a human does, so get rid of the thing that only exists for the computer's sake.

Python eliminates a whole class of bugs: ones where braces and whitespace disagree. I have had some *hellish* times debugging that kind of problem, where a single closing brace went missing somewhere in a big file.

(Python also eliminates arguments over where the opening brace goes, which is a nice bonus. :))

Re:Why Python?

[Anonymous Coward]

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

I've never in my life seen anyone say that. Most of the Python developers I know use vim or emacs. Why on earth would you need a Python-specific editor to deal with indentation? What would it even do that a regular text editor doesn't?

Second big one: "self". For those not in the know, that's the pointer to the current object. Like this in C++. Unlike most object-oriented languages, whose claim to fame is that they handle the object-orientation for you (instead of having to hack it out in C like with gobject or GTK programming), Python asks you to manually pass the current object pointer around.

You don't manually pass the current object around. You just say you expect to *receive* one. I happen to like that everything my functions receive is listed as an argument. Ethereal this/self are needlessly weird.

If it bothers you that much, observe that `def foo(self)` is one character shorter than `function foo()`.

Re:Why Python?

[Anonymous Coward]

That was finally fixed, a decade later that it should have been.

It has been? I didn't notice, but then again I've set my editor up, so the tab/spaces issue doesn't exist for me. In any case there was always the -t and -tt command line switches, not to mention s/\t/ /g.

I'm not sure how tabs even end up in code in the first place?** I mean we all in- and de-dent with the proper editor commands, not with the [tab] and [backspace] keys, don't we?

** In a modern text editor that is. It's true that old-school vi, for example, used a mix of tabs and spaces to indent.

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?

[Capsaicin]

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 done so most of us find this infamous problem simply vanishes (along with any and all tabs in the source). Indeed not only does Python's indentation ensure visually clean code, after one gets used to it, having to add curly braces and the like feels like an imposition! "*@!*!! there is *no* good reason for brace delimited blocks!! *&@*"

Having said that, I must congratulate you on finding the rather arcane X11 paste example as a potential source of problems, made all the more so by the fact that PEP 8 also stipulates using 4 spaces per indent and the X11 paste will convert a tab to 8 spaces. Bravo! :)

Re:Why Python?

[Terrasque]

Eric S. Raymond's answer

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: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 :)

Re:Why Python?

[Terrasque]

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:Why Python?

[Ginger Unicorn]

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:Why Python?

[rubikscubejunkie]

I am myself familiar with AnonymousCoward but not HearVoic .....

Re:Why Python?

[jgrahn]

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:Why Python?

[gknoy]

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 4-space indentation. Moreover, from what I've read recently, 4-spaces is less important than _consistent_ indentation. (I'll have to double check, but I think it would work with 2-space indents too, if you preferred.)

Re:Only faggots use Python...

[Anonymous Coward]

A homo sapiens? Can't argue with that...

Python Web Development with Django

[Spy Handler]

Wow, is there anything Samuel L. Jackson can't do?

Re:Python Web Development with Django

[Spy Handler]

oops, I meant Jamie Foxx... I got my Quentin Tarantino movies mixed up

Core?

[Compaqt]

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?

[jason.sweet]

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

Why an editor?

[MichaelusWF]

Why do you need an editor designed for Python? I write Python in gedit and vim reasonably often. Last time I checked both of those programs support both tabs and spaces, with no external support or plugins required...

"and is well-structured"

[Anonymous Coward]

Shouldn't it be object-oriented?

sounds like a good "next step" book

[ThorGod]

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 solutions."

Re:sounds like a good "next step" book

[thatpythonguy]

...

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?

[littlewink]

I'll wait for the Cliff's Notes version, thank you.

Python is pretty decent, I only have two concerns

[ezakimak]

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 winds up saving typing to boot.

The libraries are pretty great. The documentation could be organized better, but on the hole is fairly complete.
The community is for the most part very responsive in #irc to questions. (Just don't offend them or get obstinate about doing it a non-python way...after all the help they provide is *free*).

"ReVeRsE-PsyChoLoGy" via Python 4 a troll

[Anonymous Coward]

".hturT .omoh eguh a er'uoy nohtyP esu uoy fI" - by Anonymous Coward ANOTHER "ne'er-do-well" /. OFF-TOPIC TROLL on Monday July 30, @04:22PM (#40821797)

"???"

Uhm... Could we get a translation of that illogical ad hominem attack failed attempt @ "troll-speak/trolllanguage" of yours, please?

---

* You're just TROLL "noise", nothing more... See subject-line above, & "Rinse, Lather, & Repeat"!

APK

P.S.=> ("ReVeRsE-PsYcHoLoGy", for trolls - Courtesy of this python code by "yours truly" in less than 1 second flat):

---

#TrollTalkComReversePsychologyKiller.py (Ver #2 by APK)

def reverse(s):
          try:
                  trollstring = ""
                  for apksays in s:
                  trollstring = apksays + trollstring
          except:
                  print("error/abend in reverse function")
          return trollstring

s = ""
print reverse(s)

try:
      s = "Insert whatever 'trollspeak/trolllanguage' gibberish occurs here..."
      s = reverse(s)
      print(s)
except Exception as e:
      print(e)

---

(Yes, for the "purists" among you, I could do this via a single line print statement in Python, but to myself, that's merely using a native function - NOT truly "coding" so... there you are (Python's NOT a "primary language" for me, just one I dabbled with a year or two ago for a few months...))

... apk

When Python lets me...

[FlyingGuy]

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:When Python lets me...

[codepunk]

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"
#}

Is Wesley J. Chun running for political office?

[Anonymous Coward]

This is a pretty good review, but I could've done without all the gushing praise for the author and his accomplishments large and small (he studied piano! he has his own consulting business! he wrote a small web server!).

Re:Is Wesley J. Chun running for political office?

[Caesar Tjalbo]

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.

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

[Gorobei]

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 often "do not do GC, assume the program will terminate before you run out of memory." Tying RA to GC is a pretty significant language design choice that, as you note, affects the patterns a programmer will use. At my current gig, we make design choices like this (auto-terminate and restart processes that exceed a memlimit,) but I'd hate the language we use (and we use Python) to have its own views of resource management based on memory.

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

[ezakimak]

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

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?

And a 3rd item: if you're not gonna have goto, then at least allow break to accept a parameter to know how many levels to break out of... having to manage and test extra flags just to exit out of multiple-nested blocks at once is much less readable.

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

[Gorobei]

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 so, can I pass it do another function and do a LISP non-local goto? Can I return it from a function?

Whatever rules you pick, have you really made things easier to read or more complex?

IIRC, Erik Naggum had some interesting posts on this topic.

And a 3rd item: if you're not gonna have goto, then at least allow break to accept a parameter to know how many levels to break out of... having to manage and test extra flags just to exit out of multiple-nested blocks at once is much less readable.

Again, you can express some things more concisely, but at what cost to others reading your code? "break 9 levels" helps no one. "break 2 levels" might be better expressed as a subfunction within a simple return.

People can write amazing bad code using simple 1-level constructs like 'if' and 'break.' It should not be surprising that giving them power tools like 'multi-if' and 'multi-level-break' just lets them write worse code and get even more confused by the good code they happen to see.

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:Python is pretty decent, I only have two concer

[Anonymous Coward]

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 )