How To Let People Know You're A Bad Python Programmer

i too think the distinction between camel case and lowercase underscore as one being somehow more readable or better than the other is a little silly.

This is an oldie but a goodie, but a lot of bad programmers don't realize they can make their Python code even worse, if they embed a bunch of untested, legacy, Perl code in it. There is a Perl/Python module that makes this a snap.

Yes, throw in a Perl slight for good measure. A surer way of endearing yourself to your fellow Pythonistas, I know of not. This is not unlike what happens on reddit.com/r/programming, where an opportunity to sneer at Java is never missed, and every kind soul you encounter will gladly regale you with tales of the imaginary programs they claim to have written in Haskell or Lisp.

Perl, that miserable little unwanted orphan of a language, has real anonymous, first-class functions complete with closures. Python, sadly, does not, and that is an undeniable, glaring defect in the language. And for what reason? Because its Benevolent Dictator for Life decreed that functional programming--even in the greatly-diluted form in which one finds it in mainstream languages--is bad and "unpythonic"--heretical, essentially. He recently lashed out against tail call optimization, and before that attempted to exile some Lisp constructs that had been resident in the language for many years, but back-peddled as soon as his subjects threatened to revolt.

When Python catches up to Perl, Ruby, Javascript and every other decent dynamic language in this department, then you can condemn Perl as much as you like. Until that time, hold your tongue.

Python is not really a functional programming language -- it has statements and suites, neither of which are first-class.

lambda is implemented as an inline (suite-less) value-returning statement (like the ternary statement) because dealing with indentation would be a bitch. Since statements cannot contain other statements outside of suites, it's impossible to implement full-fledged anonymous functions in the language grammar without breaking something.

While I'd love TCO in python, I like the stack traces better (ever dealt with a stray head [] in GHC?).

A coworker found that calling out to grep can be faster than using Python's regular expressions for large amounts of text processing. My first reaction was to cringe, but it was indeed much faster for this particular problem; I think I was the bad programmer for reflexively cringing instead of saying "nice performance hack".

If he had meant only that and meant nothing more, he wouldn't have singled out Perl, or he would have done so in a more tactful manner. And ask yourself, is this really a big problem? How often have you actually seen someone embed Perl (or any other language) in Python? Why is that admonition sandwiched between remarks on unit testing and maintaining control flow?

On another note, everyone seems to love anonymous, first-class functions with closures, and yet they never give nontrivial examples - what am I missing out on?

Spend some time with a language that not only supports them but actually encourages their use, and you will see for yourself. For example, both Smalltalk and Ruby make heavy use of blocks, and because of that classes can be written to allow users to greatly customize their behavior without the need of subclassing.

(For that matter, I still haven't seen what TCO offers that is new, but that was April's issue.)

TCO allows programs to, in certain circumstances, reuse existing stack frames for possibly many function invocations. For example, if a function is written to be tail recursive, a VM with TCO could reuse the same stack frame for each recursive function invocation until the terminating condition is reached, at which point the last return value is caught and the frame is popped off the stack. (TCO isn't strictly limited to making tail recursion more efficient, but that is its most often cited benefit.)

The main reason Guido and his Pythonistas have no use for TCO is that they also have no use for recursion. If Python supported TCO, more recursive Python code would probably be written--and that would be very unpythonic.