Skip to main content

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.

Comments

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.
10:56 AM
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.
12:40 PM
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).
8:14 AM
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?
6:50 AM
Post a Comment