« Surface Tension | Main | RDFa and QNames in content »

Python Pain Points

"What Are Your Python Pain Points, Really?"

Not that many:

  • str v unicode
  • HTTP libraries - the best one isn't in the stdlib.
  • Method signatures - if optional types ever landed, I'd use them in method signatures.
  • self - more of an irritant than actually painful.
  • No multiline lambdas -cue standard whining about how Ruby has closures.
  • No SMP/core support - this is not the same thing as wanting threads.
  • Jython being behind Python - you have to be careful about targeting versions.

A few years ago I would have put IDEs up there, but now there's PyDev.

June 4, 2007 07:29 PM


(June 4, 2007 07:43 PM #)

add: 'native' rfc-compliant handling of URIs

Ian Bicking
(June 4, 2007 08:25 PM #)

You are misusing the term closure. Python has closures. I know what you mean, but your terminology is misleading. You probably mean something like "function expressions". Or maybe you mean "writable closures", but that doesn't have anything to do with lambda. That is a bit annoying, but most people don't really realize it's annoying because they don't use closures much, because the syntax doesn't make it feel very rewarding.

And multi-line lambda would be incredibly ugly. There'd have to be some other kind of syntax.

Seairth Jacobs
(June 5, 2007 12:19 AM #)

Would there even be an advantage for using a multi-line lambda over a defined function with a return value? The net result would be the same, but maybe there is something I am missing about multi-line lambdas that would make them better in some cases.

(June 5, 2007 07:07 AM #)

"maybe there is something I am missing"

Some people have serious problems coming up with names. But my guess is most people that complain about this simply don't understand that the 'def' statement is a light-weight operation that creates an object from prefabricated components, and assigns it to a variable in the current scope; local functions are very cheap in Python.

Ian Bicking
(June 5, 2007 03:44 PM #)

There can be an out-of-order problem with defining a function (an aesthetic, not functional problem). Typically if you are using a construct like a callback, typically the order of execution is that some function or handler does some work, then it calls the callback. But in the source code you have to define the callback before you call the function that uses the callback. If you do a *lot* of callbacks, it ends up feeling like you are writing your code backwards, defining the final steps of the process first and slowly working your way back to the invocation that actually sets everything in motion.

Bill de hOra
(June 5, 2007 08:19 PM #)

"Some people have serious problems coming up with names. "

I love it. That's so... polite :)

Rob Sayre
(June 6, 2007 05:59 AM #)

I hate the way Python makes you name functions, even though they don't usually clutter the end result. It is convenient to start writing things before you know what they should do. Since you don't quite know what the function is supposed to do, it is hard to think up a good name.

(June 10, 2007 10:48 AM #)

Hey Rob.

I don't know if you were serious or not but that's pretty profound.

(June 11, 2007 12:29 AM #)

I hope Rob wasn't being serious. If you don't know what your function is supposed to do (and therefore name it), should you really be writing he body to begin with?

(June 11, 2007 12:37 AM #)

The issue I always had with python's named inner functions vs multi line lambdas was that I didn't want to attach a name to the method. It wasn't relevant to what was going on.

If I want to create a function that returns another function, then that's quite simply what I want to do. I don't want there to be a 'def anonymousfunc:... return anonymousfunc', I just want to type 'return def:...'

Why can't I do that? why must python make me assign a name for something that doesn't have one? It's just annoying. Yes it's syntactic sugar, but some sugar is very valuable


(June 11, 2007 02:19 AM #)

Python has 'closures' too. You probably mean blocks :)

(June 11, 2007 05:16 AM #)

My goodness! I've heard this from other pythonistas, before, too. Why is it so hard to understand that anonymous functions are useful things? Suppose you meet someone who has only ever programmed in a language that required all numbers and strings to be named: how would you feel being forced to justify why such crazy things as "anonymous numbers" were useful?

Certainly if you're going to use a number in your program, you should know what it is and what it's for! Don't say: "d*24*60*60"; you should first define that 24 is numberOfHoursInDay, and that 60 is both numberOfMinutesInHour and numberOfSecondsInMinute! Only then can you write "d * numberOfHoursInDay * numberOfMinutesInHour * numberOfSecondsInMinute"! This is what it feels like when I hear python people try to force me to justify the utility of anonymous functions.

But, at any rate, I'll still give yet another justifying example: specifying a large data-structure with embedded functions. Say I'm building a dict (or a dict of dicts or dict of arrays of dicts, etc), in which some of the values are functions... functions that are used nowhere else, except as the values in that dict. It is painfully annoying to be forced to write the code for those functions all together up above the start of the dict, give them all lame names (probably just some stringification of the path to the key in the dict), and repeat it down inside the dict structure. Worse yet: what if I'm constructing an array of functions out of a map or a list comprehension: now I've got to define a function-builder function up above and call that inside a lambda inside the map. That's awesome! That really feels like my language is working for me and not working against me!

P.S. Yeah, you can do that all super easy in Perl or Ruby or JavaScript or Scheme or Lisp, but no: this isn't about comparing Python to its kin; it's about saying: What the hell, Python? Moreover: What the hell Python community, that stubbornly acts like this isn't a problem to be missing this really, incredibly useful functionality!? Do you really not get it, or is this just sticking your fingers in your ears and pretending like a problem is not a problem because it's your baby, and you don't want to hear anything bad said about it?

(June 11, 2007 07:13 AM #)

>My goodness! I've heard this from other pythonistas, before, too. Why is it so hard to understand that anonymous functions are useful things?

Why is it so hard for people to realize that other people draw their line somewhere else in the sand?

I agree, anonymous functions are useful. I would expect that is a widespread opinion amongst people who appreciate functional programming.

The problem with python is that the syntax doesn't support a multi-line lambda. A lot of people like the python syntax for other reasons, so they put up with the pain of only having an anonymous function for one line functions, and having to come up with a (sensible) name for a more complicated function.

The pain of having to name each number (per the absurd example) is obviously more than almost anyone will tolerate, pythonista or otherwise.

But it seems there are a significant number of pythonistas for whom the requirement to name non-trivial functions does not cross the line.

Andrew Gwozdziewycz
(June 11, 2007 01:26 PM #)

For all people complaining that Python doesn't need to have anonymous multi-line functions, see Paul Grahams essay, Beating the Averages http://www.paulgraham.com/avg.html which defines the Blub Paradox.

(June 11, 2007 01:46 PM #)


It's like complaining about parens in lisp. Hopefully the following code will be formatted well by the comment engine.

def anonymous(foo):
def anonymous(foo):
# etc...

Is it really so horrible that you have to do that instead of the following?

callback_func(callback=lambda foo:

In fact, I think this would be more of a non-issue if there were no lambdas (that is, if lambda was not a reserved keyword, and you could use that instead of anonymous in the first example)

(June 11, 2007 01:52 PM #)

(Anyway, I guess you were defending the lack of multi-line lamdas. Apologies.)

(June 12, 2007 02:44 AM #)

Andrew Gwozdziewycz,

re your comment about Blub, isn't that more about whether a given technique is even possible, rather than about minor syntactical pain?

I would have a real problem with python if it wasn't possible to create a function on the fly and treat it like any other object. The fact that I have to name it is a pain, but not unbearable.

On the other hand, no macros - that really does affect what sort of programming you can do with python. Possibly the Blub Paradox explains why no-one (including me) has complained about lack of macros in python?

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry: