2012-07-27 19 views
5

Cada vez que creo entender el módulo de registro, los gremlins entran y cambian la forma en que funcionan. (Ok, lo admito, ese gremlin puede ser que cambie mi código.)Configuración de registradores secundarios

¿Qué estoy haciendo mal aquí?

> ipython 
> import logging 
> log = logging.Logger("base") 
> log.addHandler(logging.StreamHandler()) 

> log.critical("Hi") 
Hi 

> log2 = log.getChild("ment") 

> log2.critical("hi") 
No handlers could be found for logger "base.ment" 

podría haber jurado que en el pasado, yo era capaz de utilizar los registradores de niño sin configuración adicional ...

+0

Pruébelo en una sesión nueva. Funciona para mí usando ipython, y también como script. – unutbu

+0

No funciona para mí tampoco en cPython 2.7.2. Me pregunto si tiene algo que ver con la configuración predeterminada de un 'StreamHandler' ... Cuando creo' log', agrego el controlador a 'log', luego creo' log2', obtengo 'No handlers', pero si creo 'log2' primero y luego agrego el manejador a' log', el registro en 'log2' no genera errores (aunque tampoco imprime nada). –

+0

@unutbu: Hmmm ... esa * es * una nueva sesión. Incluí la línea de comando 'ipython' en la parte superior para indicar eso. Que puedas ejecutar esto sin problemas me da un mal presentimiento. Estoy ejecutando Python 2.7.1 e IPython 0.10. Sido así por un tiempo * largo *, así que ese no parece ser el problema. Yo * sé * tiene que ver con mi código ... –

Respuesta

5

Si cambia

log = logging.Logger('base') 

a

log = logging.getLogger('base') 

entonces funciona:

import logging 

log = logging.getLogger('base') 
log.addHandler(logging.StreamHandler()) 
log.critical('Hi') 
log2 = log.getChild('ment') 
log2.critical('hi') 

produce

Hi 
hi 
+0

Estaba a punto de intentarlo ... ¡buena captura y gracias por la ayuda! +1 –

+2

Argh, acabo de rastrear esto ... Sí, el módulo de registro invisiblemente realiza un proxy a través de 'logging.Manager' para crear registradores. Cuando crea directamente un registrador con 'logging.Logger()', cortocircuita el sistema y las cosas se vuelven locas. –

+0

Busqué en mis versiones mercuriales y eso es exactamente lo que sucedió."Limpié" mi código de registro y escribí "Logger" en lugar de "getLogger". @ sr2222: Gracias por perseguir la causa. Ayuda a saber por qué falló. Ahora puedo cambiar mi modelo mental de "registro de carga y crear un registrador" a "cargar registro y crear un registrador hijo". +1. ¡Gracias! –

1

más detalle: Usted está utilizando el módulo equivocado. :) Al mirar el código del módulo, parece que no esperan que crees un logging.Logger() directamente. Muchas de las funciones disponibles directamente en el módulo (ex getLogger()) y los métodos en logging.Logger() (ex getChild()) son realmente proxy a través de una instancia de logging.Manager que el módulo crea en la importación. Cuando crea un Logger con logging.Logger() directamente, en realidad está creando una instancia Logger fuera del Manager. Cuando posteriormente llama al log.getChild(), el módulo está realmente creando el nuevo registrador dentro del Manager, pero con el nombre del registrador externo Manager adjunto al frente del nombre del registrador. Por lo tanto, su controlador agregado a log no está en el Manager con el hijo generado, y por lo tanto, el controlador no funciona. Todavía estoy un poco confundido sobre por qué agregar un controlador a log antes o después de crear log2 hace que el registro en contra de log2 se comporte de manera diferente. No veo qué está causando eso ...

+0

: "con logging.Logger() directamente, en realidad está creando una instancia de Logger fuera del Manager. Cuando posteriormente llama a log.getChild(), el módulo está realmente creando el nuevo registrador dentro del administrador "Interesante. Y tiene sentido. Debo recordar siempre pensar "crear sublogger" ... incluso al crear el "primer" registrador de * my * program. –

Cuestiones relacionadas