This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients chris.jerdonek, docs@python, rhettinger
Date 2012-07-12.15:45:46
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1342107947.01.0.0483144600568.issue15329@psf.upfronthosting.co.za>
In-reply-to
Content
I think you're over-reaching.   We make almost no guarantees about atomicity.  Having multiple implementations of Python makes that an even harder task.  

In general, critical sections need to be guarded with locks.  If an object claims to be thread-safe, it means that it has used locks (perhaps relying on the GIL) to guard its own critical sections.  

Almost any pure Python class with complex state and without locks is not thread-safe (for example, an insertion into an OrderedDict needs to update the two dicts and a doubly-linked list).

Classes written in C are necessarily thread-safe (they rely on the GIL) or else they would risk segfaulting.  Other implementations are free to make different decisions about which classes are thread-safe. Pypy tends to make fewer guarantees because it implements more classes in pure python.  Jython tends to make strong guarantees because it uses Java's concurrent mappings and other such tools.

For the most part, the docs have done the right thing by not making any promises.  It might be helpful though to have a HOWTO guide explaining the facts-of-life when doing multi-threading (i.e. don't assume anything is atomic or thread-safe unless explicitly promised and don't expect many such promises).
History
Date User Action Args
2012-07-12 15:45:47rhettingersetrecipients: + rhettinger, chris.jerdonek, docs@python
2012-07-12 15:45:47rhettingersetmessageid: <1342107947.01.0.0483144600568.issue15329@psf.upfronthosting.co.za>
2012-07-12 15:45:46rhettingerlinkissue15329 messages
2012-07-12 15:45:46rhettingercreate