pylint 1.4 informa E1101 (no miembro) en todas las extensiones C

Hemos sido fanáticos del pylint desde hace mucho tiempo. Su análisis estático se ha convertido en una parte crítica de todos nuestros proyectos de python y ha ahorrado toneladas de tiempo persiguiendo errores oscuros. Pero después de actualizar desde 1.3 -> 1.4, casi todas las extensiones c comstackdas dan como resultado errores E1101 (sin miembro).

Los proyectos que anteriormente se ejecutaban perfectamente limpios a través de pylint 1.3 ahora se quejan de casi todos los miembros de la extensión C con E1101. Nos hemos visto obligados a deshabilitar los errores de E1101, pero esto resta importancia material a la utilidad del pylint .

Por ejemplo, este uso perfectamente válido del paquete lxml .

 r"""valid.py: demonstrate pylint 1.4 error""" from lxml import etree print etree.Element('mydoc') 

Ejecutar esto a través de pylint , y se informa:

 $ pylint -rn valid.py No config file found, using default configuration ************* Module valid E: 3, 6: Module 'lxml.etree' has no 'Element' member (no-member) 

Pero es perfectamente válido:

 $ python valid.py  

Aquí es donde se pone realmente raro. Un puñado muy pequeño de extensiones en C parece funcionar bien a través del pylint , por ejemplo:

 r"""valid2.py: this one works fine""" import sqlite3 print sqlite3.version $ pylint -rn valid2.py No config file found, using default configuration 

Mi pregunta es, ¿Alguien más ha sido testigo de esto? Y si es así, ¿estaría dispuesto a compartir su solución / solución?

Hemos experimentado con el bash de crear complementos para suprimir estas advertencias ( http://docs.pylint.org/plugins.html#enter-plugin ), pero estamos teniendo dificultades para hacer caras o colas de los documentos, y la astroid clase base de astroid es súper compleja y ha desafiado nuestros bashs de asimilarla.

Para obtener puntos de bonificación reales (y nuestra gratitud eterna) nos encantaría entender qué ha cambiado en el pylint . Nos complacería arreglar el código (o al menos publicar un documento de mejores prácticas para los autores de extensiones C) que satisfaga al pylint .

Detalles de la plataforma

 $ pylint --version No config file found, using default configuration pylint 1.4.0, astroid 1.3.2, common 0.63.2 Python 2.7.5 (default, Jul 1 2013, 18:09:11) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] 

Poco después de publicar mi pregunta, encontré la respuesta. De hecho, el cambio se realizó a propósito como medida de seguridad. Pylint importa módulos para identificar efectivamente métodos y atributos válidos. Se decidió que la importación de extensiones c que no forman parte de la plataforma estándar de Python es un riesgo de seguridad y podría introducir códigos maliciosos.

Esto se hizo en el lanzamiento de Astroid 1.3.1 https://mail.python.org/pipermail/code-quality/2014-November/000394.html

Solo las extensiones C de fonts confiables (la biblioteca estándar) se cargan en el proceso de examen de Python para construir un AST desde el módulo en vivo.

Hay cuatro soluciones si desea usar pylint en proyectos que importan extensiones no stdlib c.

1) Desactive la seguridad utilizando la opción de línea de comando --unsafe-load-any-extension=y . Esta función no está documentada y se clasifica como una opción oculta ( https://mail.python.org/pipermail/code-quality/2014-November/000439.html ).

2) Deshabilite la seguridad utilizando la configuración pylint.rc unsafe-load-any-extensions=yes . Se recomienda sobre la opción 1 e incluye la documentación completa en el archivo pylint.rc predeterminado (creado con --generate-rcfile ).

3) Especifique específicamente los paquetes o los nombres de los módulos en los que confía para ser cargados por pylint en el archivo pylint.rc usando la opción extension-pkg-whitelist= .

4) Cree un complemento para manipular el AST (no tengo idea de cómo hacer esto, pero se analiza regularmente en la lista de correo de pylint).

Optamos por la Opción 3. pylint.rc la siguiente línea a nuestro archivo pylint.rc proyecto:

 extension-pkg-whitelist=lxml 

@ user590028, muchas gracias por tu respuesta! Acabo de encontrar este mismo problema con las bibliotecas win32api, win32evtlog, win32file, win32gui y win32process, y su solución funcionó.

Usé otro método que creo que vale la pena publicar aquí, que es llamar a pylint y pasar los paquetes incluidos en la lista blanca como un parámetro:

 pylint --extension-pkg-whitelist=win32api,win32evtlog,win32file,win32gui,win32process myfile.py 

Para aquellos de ustedes que usan VS Code, es un poco difícil encontrar dónde colocar el comando ya que no pude encontrar mi ejecutable.

En el código VS;

  1. haga clic en Archivo> Preferencias> Configuración.
  2. Desplácese hasta “Configuraciones de Python” en la ventana izquierda
  3. desplácese hacia abajo hasta “Python Linting: Mypy Args” en la ventana derecha
  4. Haga clic en el enlace “Editar en settings.json”
  5. edite el json para incluir: “–extension-pkg-whitelist =”

Tuve que hacer todo esto porque PyLint no es ejecutable desde mi línea de comandos de Windows …

Si está utilizando VS Code para Mac, esto es lo que necesita hacer para editar el archivo settings.json:

  1. Haga clic en Código (es decir, en la pestaña Código de Visual Studio que se encuentra a la izquierda de la pestaña ‘Archivo’) -> Preferencias -> Configuración
  2. Desplácese hasta Extensiones y haga clic en Python en la lista.
  3. Haga clic en cualquiera de los enlaces Edit in settings.json . Esto abre settings.json para editar.
  4. Agregue la línea "python.linting.pylintArgs": ["----extension-pkg-whitelist=1xml"] .