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.
5 comments:
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.
My fault for providing insufficient context.
I (and the linked presentation) are referring to the synchronization classes provided by the threading module.
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).
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?)
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?
Post a Comment