[Python-Dev] Issue 14417: consequences of new dict runtime error

[Etienne Robillard]

On 03/29/2012 04:48 PM, R. David Murray wrote:
> On Thu, 29 Mar 2012 16:31:03 -0400, "R. David Murray"<rdmurray at bitdance.com>  wrote:
>> On Thu, 29 Mar 2012 13:09:17 -0700, Guido van Rossum<guido at python.org>  wrote:
>>> My original assessment was that this only affects dicts whose keys
>>> have a user-implemented __hash__ or __eq__ implementation, and that
>>> the number of apps that use this *and* assume the threadsafe property
>>> would be pretty small. This is just intuition, I don't have hard
>>> facts. But I do want to stress that not all dict lookups automatically
>>> become thread-unsafe, only those that need to run user code as part of
>>> the key lookup.
>>
>> You are probably correct, but the thing is that one still has to do the
>> code audit to be sure...and then make sure that no one later introduces
>> such an object type as a dict key.
>
> I just did a quick grep on our project.  We are only defining __eq__
> and __hash__ a couple places, but both are objects that could easily get
> used as dict keys (there is a good chance that's *why* those methods are
> defined) accessed by more than one thread.  I haven't done the audit to
> find out :)
>
> The libraries we depend on have many more definitions of __eq__ and
> __hash__, and we'd have to check them too.  (Including SQLAlchemy,
> and I wouldn't want that job.)
>
> So our intuition that this is not common may be wrong.
>
> --David
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/animelovin%40gmail.com
>

Hm, as far I understand this seems like an issue for gnu PTH, not python 
job, which should transparently handles thread safety
issues based on the host/machine capabilities. Therefore I hope the fix 
in python don't affect thread-unsafe apps to raise spurious 
RuntimeErrors when a dict get modified across a SMP-aware platform... :-)