python - scikit-regresor forestal aleatorio-AttributeError: el objeto ''Thread'' no tiene el atributo ''_children''

flask scikit-learn

Question

Recibo el siguiente error al configurar mi parámetro n_jobs> 1 para el regresor de bosque aleatorio. Si configuro n_jobs = 1, todo funciona.

AttributeError: el objeto ''Thread'' no tiene el atributo ''_children''

Estoy ejecutando este código en un servicio de matraz. Lo interesante es que no ocurre cuando se ejecuta fuera del servicio del matraz. Solo reproduje esto en una caja Ubuntu recién instalada. En mi Mac, funciona bien.

Este es un hilo que hablaba de esto, pero no parecía ir a ningún lado más allá de la solución El objeto ''Thread'' no tiene el atributo ''_children'' - django + scikit-learn

Tiene alguna idea sobre esto?

¡Gracias a todos!

Aquí está mi código de prueba:

@test.route(''/testfun'') def testfun(): from sklearn.ensemble import RandomForestRegressor import numpy as np train_data = np.array([[1,2,3], [2,1,3]]) target_data = np.array([1,1]) model = RandomForestRegressor(n_jobs=2) model.fit(train_data, target_data) return "yey"

Stacktrace:

Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1836, in __call__ return self.wsgi_app(environ, start_response) File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1820, in wsgi_app response = self.make_response(self.handle_exception(e)) File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1403, in handle_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1817, in wsgi_app response = self.full_dispatch_request() File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1477, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1381, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1475, in full_dispatch_request rv = self.dispatch_request() File "/usr/local/lib/python2.7/dist-packages/flask/app.py", line 1461, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/home/vagrant/flask.global-relevance-engine/global_relevance_engine/routes/test.py", line 47, in testfun model.fit(train_data, target_data) File "/usr/local/lib/python2.7/dist-packages/sklearn/ensemble/forest.py", line 273, in fit for i, t in enumerate(trees)) File "/usr/local/lib/python2.7/dist-packages/sklearn/externals/joblib/parallel.py", line 574, in __call__ self._pool = ThreadPool(n_jobs) File "/usr/lib/python2.7/multiprocessing/pool.py", line 685, in __init__ Pool.__init__(self, processes, initializer, initargs) File "/usr/lib/python2.7/multiprocessing/pool.py", line 136, in __init__ self._repopulate_pool() File "/usr/lib/python2.7/multiprocessing/pool.py", line 199, in _repopulate_pool w.start() File "/usr/lib/python2.7/multiprocessing/dummy/__init__.py", line 73, in start self._parent._children[self] = None

Answer 1

El problema

Esto probablemente ocurre debido a un error en multiprocessing.dummy (ver aquí y aquí ) que existía antes de Python 2.7.5 y 3.3.2.

Solución A: actualización de Python

Vea los comentarios para la confirmación de que una nueva versión funcionaba para OP.

Solución B - Modificar dummy

Si no puede actualizar, pero tiene acceso a .../py/Lib/multiprocessing/dummy/__init__.py , edite el método de start dentro de la clase DummyProcess la siguiente manera (debe ser ~ línea 73):

if hasattr(self._parent, ''_children''):  # add this line
    self._parent._children[self] = None  # indent this existing line

Solución C - Parche de mono

DummyProcess es donde existe este error. Veamos dónde está el código importado para asegurarte de que lo apliquemos en el lugar correcto.

• RandomForestRegressor
• hereda: ForestRegressor
• hereda: BaseForest
• creado en: sklearn.ensemble.forest
• which imports: Paralelo de sklearn.externals.joblib
• que importa ThreadPool de multiprocesamiento.pool
• que importa y almacena el proceso de multiprocessing.dummy
• que ha sido asignado a: DummyProcess también en multiprocessing.dummy

La existencia de DummyProcess en esa cadena garantiza que ya se importó después de la importación de RandomForestRegressor . También creo que tenemos acceso a la clase DummyProcess antes de que se realicen instancias de ella. Por lo tanto, podemos parchar la clase una vez en lugar de tener que buscar instancias para parchar.

# Let''s make it available in our namespace:
from sklearn.ensemble import RandomForestRegressor
from multiprocessing import dummy as __mp_dummy

# Now we can define a replacement and patch DummyProcess:
def __DummyProcess_start_patch(self):  # pulled from an updated version of Python
    assert self._parent is __mp_dummy.current_process()  # modified to avoid further imports
    self._start_called = True
    if hasattr(self._parent, ''_children''):
        self._parent._children[self] = None
    __mp_dummy.threading.Thread.start(self)  # modified to avoid further imports
__mp_dummy.DummyProcess.start = __DummyProcess_start_patch

A menos que haya omitido algo, a partir de ahora todas las instancias de DummyProcess creadas serán parcheadas y, por lo tanto, ese error no ocurrirá.

Para cualquiera que haga un uso más extenso de sklearn, creo que puede lograr esto a la inversa y hacer que funcione para todos los sklearn en lugar de enfocarse en un solo módulo. Deberá importar DummyProcess y DummyProcess parche como se DummyProcess anteriormente antes de realizar cualquier importación de sklearn. Entonces sklearn usará la clase parcheada desde el principio.

Respuesta original:

Mientras escribía el comentario, me di cuenta de que podría haber encontrado su problema: creo que su entorno de matraz está usando una versión anterior de python.

La razón es que en la última versión del multiprocesamiento de python, la línea donde está recibiendo ese error está protegida por una condición:

if hasattr(self._parent, ''_children''):
    self._parent._children[self] = None

Parece que este error se solucionó durante Python 2.7 (creo que se corrigió desde 2.7.5). ¿Tal vez su matraz es un 2.7 o 2.6 anterior?

¿Puedes verificar tu entorno? Si no puede actualizar el intérprete, tal vez podamos encontrar una forma de multiprocesamiento de parche mono para evitar que se estrelle.