Monday, June 13, 2005

I figured out why Python's threading library bugs me

Reading Aahz's 2001 OSCon presentation, I ran into a slide that crystalized it [paraphrased]:

  • Perl: There's more than one way to do it
  • Python: There should be one (preferably only one) obvious way to do it
  • Python's threading library is philosophically perl-ish

That pretty much says it all. Well, that and the main classes are (still) virtually undocumented.

Update: I'm referring to the synchronization classes in this module, not the Thread class, which is straightforward enough.


Ian Bicking said...

What's the other way? I always use threading, and that's about it. I guess you can choose to subclass threading.Thread, or you can just use the target argument to Thread, but that's not a huge difference in practice. Certainly I don't like the fact that there's a class at all, a simple function-based interface would be much nicer; another case of inappropriate Java conventions. But eh, it's not that big a deal.

Jonathan Ellis said...

My fault for providing insufficient context.

I (and the linked presentation) are referring to the synchronization classes provided by the threading module.

Tim Lesher said...

I don't have a problem with the number of sync objects, really. It seems to me a case of horses for courses. The documentation is decent but not exhaustive--or are you talking about the lack of docstrings?

At any rate, I'm more concerned about the lack of "debuggability" of Python threads (although I haven't re-checked this since around Python 2.2).

Kevin Dangoor said...

I was initially going to post that the classes are there to solve different problems... but then I read the (somewhat sparse) documentation and noticed that the distinction between Condition and Event and between Semaphore and Lock are really not described well at all.

I'm all for the standard library provided higher-level routines based on lower-level constructs (and including the lower-level ones, if you need to customize behavior), but those four classes really could use a bit more descriptive text to say why you would choose one over the other... (and if you wouldn't, that seems like a good thing to start deprecating, no?)

Anonymous said...

There are lots of other things to dislike about python threads. How about the global interpreter lock? Or the inability to send an asynchronous signal to a particular thread? Or all the boilerplate code that has to be present just to start a thread the "right" way?