Thursday, 4 June 2009

Python pains, part 1

I’ve been a devoted python hacker for almost a decade, and I don’t plan to back off (at least unless Python 3000 forces out 2.x). I program in dozens of other languages, but whenever I need to hack something up, python’s almost always the choice for me. Still, there are things I miss/dislike about it, and I plan to dedicate a couple of posts to them.

The first thing I don’t like is the semantics of list methods. Those methods always disrupt the fp-ish flow of my script. I want to write:

But I have to write:

And that only if I won’t need the original value of a!

The point is: if I ever want to mutate the original list, I’d be willing to write something like a = a.reverse(). On the other hand, assuming that this is what I always want is far-fetched and limiting to my functional way of thinking.

The universal solution would be to make a library of wrappers like this:

Which is ugly (see for yourself), not integrated (a.append(b) vs append_(a,b)) and involves a lot of copying—more than probably really required. So, for better or worse, I end up each time implementing only wrappers specific to my current app.


  1. This is a nice feature in Ruby where you have methods like sort and sort! (the latter changes the list in-place).

    I think the reason for this Python behavior is performance, however, but I agree it's not great.

  2. That’s indeed ruby’s power (and its doom): it has a separate method for everything. Truly, everything.

    I don’t even mind python’s in-place editing, it was a conscious design choice after all, but why do the methods return None, is beyond me.