[issue12227] multiprocessing.Pool initialization seems to call methods it should not (and on badly formed objects)

2011-05-31 Thread Graham Cummins

New submission from Graham Cummins :

When attempting to pass instances of a custom class in the argument list
of a multiprocessing.Pool.map call, I encounter an inexplicable AttributeError. 
A simplified test script that creates the bug is included. It fails for both 
Python 2.7.1 and 3.2 on my 4-core 64 bit linux machine.

Briefly, the code creates a subclass of "dict" that checks for a "_ro" 
attribute before handling a "__setitem__". Empty instances of this class
can be passed to Pool.map fine, but if they have any content, I get
that multiprocessing/queues.py, line 378 ("recv()"), calls my custom 
__setitem__, which fails, due to a missing _ro attribute. 

This is very confusing. For one thing, much of the Traceback seems
missing. recv() is not directly a call to my customized __setitem__, 
and I can't thing why it should ever need to invoke such a call  

For another, the custom class _does_ set the _ro attribute, on __init__. 
Testing for this attribute, or calling __setitem__, succeeds in every other 
context I've tested, so it seems that the instance that is 
being used in the multiprocessing context is not the same underlying object 
that I pass in.

--
components: Library (Lib)
files: bug.py
messages: 137373
nosy: Graham.Cummins
priority: normal
severity: normal
status: open
title: multiprocessing.Pool initialization seems to call methods it should not 
(and on badly formed objects)
versions: Python 2.7
Added file: http://bugs.python.org/file22211/bug.py

___
Python tracker 
<http://bugs.python.org/issue12227>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue12227] multiprocessing.Pool initialization seems to call methods it should not (and on badly formed objects)

2011-05-31 Thread Graham Cummins

Graham Cummins  added the comment:

As far as I can tell, this is a version of the scope-dependent un-pickling 
issue mentioned in the documentation. I'm still rather confused, since in the 
original occurrence of the issue happens despite the fact that subprocesses 
should be able to import all relevant modules (unless they have a very odd 
environment), and the original class is pickleable. Still, until I can clearly 
distinguish my difficulty from the know issues presented in the programming 
guidelines, I see no reason to have it listed as a bug.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 
<http://bugs.python.org/issue12227>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com