'de X import a' versus 'import X; X.a'

Question

que he visto algunos programadores de Python utilizan el estilo siguiente manera consistente (lo llamaremos estilo 1):

import some_module 
# Use some_module.some_identifier in various places. 

Para el apoyo de este estilo, se puede citar la máxima de "explicit is better than implicit". He visto otros programadores utilizan este estilo (estilo 2):

from some_module import some_identifier 
# Use some_identifier in various places. 

La principal ventaja que veo en el estilo 2 es mantenibilidad - especialmente con duck typing ideales es posible que quiera cambiar some_module para some_other_module. También siento que el estilo 2 gana puntos con la máxima "readability counts". Aunque tiendo a estar en desacuerdo, siempre se puede argumentar que buscar y reemplazar es una buena opción cuando se usa el primer estilo.

Adición: Se observó que se podía utilizar as para resolver el cambio de some_module a some_other_module en estilo 1. Se me olvidó mencionar que también es común a decidir aplicar some_identifier en su módulo actual, que hace que la creación de un contenedor equivalente some_module sea un poco incómodo.

Answer 1

Hay usos para ambos casos, así que no creo que esto es una o la otra cuestión . me gustaría considerar el uso del módulo de import x,y,z cuando:

• Hay un número bastante reducido de cosas para importar

• El propósito de las funciones importadas es obvio cuando se divorció del nombre del módulo. Si los nombres son bastante genéricos, pueden chocar con otros y decir poco. p.ej. ver remove le dice poco, pero os.remove probablemente indicará que está tratando con archivos.

• Los nombres no entran en conflicto. Similar a lo anterior, pero más importante. Nunca hacer algo como:

  from os import open 
  

import module [as renamed_module] tiene la ventaja de que da un poco más de contexto sobre lo que se llama cuando se utiliza. Tiene la desventaja de que esto es un poco más abarrotado cuando el módulo realmente no está dando más información, y es un poco menos eficiente (2 búsquedas en lugar de 1).

También tiene ventajas cuando se prueba (por ejemplo, reemplazar el sistema operativo).abrir con un objeto simulado, sin tener que cambiar cada módulo), y se debe usar cuando se usan módulos mutables, p.

import config 
config.dburl = 'sqlite:///test.db' 

En caso de duda, siempre me quedo con el estilo import module.

Answer 2

Con la existencia de la siguiente sintaxis:

import some_other_module as some_module 

el argumento de mantenimiento del estilo 2 ya no es relevante.

Tiendo a usar el estilo 1. Normalmente, me parece que hago referencia explícitamente al nombre del paquete importado solo unas pocas veces en un programa típico de Python. Todo lo demás son métodos en el objeto, que por supuesto no necesitan referenciar el paquete importado.

Answer 3

Normalmente utilizo un umbral para decidir esto. Si quiero usar un montón de cosas dentro de some_module, voy a utilizar:

import some_module as sm 
x = sm.whatever 

Si hay sólo una o dos cosas que necesito:

from some_module import whatever 
x = whatever 

Eso suponiendo que no necesitan una whatever desde some_other_module, por supuesto.

Tiendo a utilizar la cláusula as en las importaciones para que pueda reducir mi tipeo y sustituir otro módulo con bastante facilidad en el futuro.

Answer 4

Creo en las nuevas versiones de Python incluso se puede hacer (2.5+ debe comprobar mis hechos ...?):

import some_other_module as some_module 

Por lo que aún puede ir con estilo 1 y de intercambio en un módulo diferente en el futuro en.

Creo que, en general, se asigna a la cantidad que desea llenar su espacio de nombres. ¿Estarás usando uno o dos nombres en el módulo? O todos ellos (from x import * no siempre es malo, solo en general)?

Answer 5

me parece que la notación

from some_module import some_symbol 

funciona mejor en la mayoría de los casos.Además, en caso de conflicto de nombres para el símbolo, puede utilizar:

from some_module import some_symbol as other_symbol 

Como los estados de interrogación, se evita volver a escribir el nombre del módulo todo el tiempo, cada vez con un riesgo de escribir mal él. Yo uso la sintaxis:

import module [as other_module] 

Sólo en dos casos:

1. utilizo también muchas de las funciones del módulo/objetos para importarlos todos
2. El módulo define un símbolo que puede cambiar durante la ejecución

Answer 6

Prefiero import X y luego uso X.a tanto como sea posible.

Mi excepción se centra en los módulos profundamente anidados en un gran marco como Django. Sus nombres de módulo tienden a ser largos, y todos sus ejemplos dicen from django.conf import settings para que ahorre tipeando django.conf.settings.DEBUG en todas partes.

Si el nombre del módulo está profundamente anidado, la excepción es usar from X.Y.Z import a.

Answer 7

Personalmente trato de no hagas demasiadas cosas en mi espacio de nombres, por lo que en la mayoría de las situaciones que acabo de hacer

import module 

o módulo de importación como mod

diffrence La única verdadera es cuando tengo un módulo con una sola clase que se usa mucho. Si hubiera un tipo sublclassed list añadir fincionalidades allí, que haría uso de

from SuperImprovedListOverloadedWithFeatures import NewLIst 
nl = NewList() 

etc.

Answer 8

que tienden a utilizar sólo unos pocos miembros de cada módulo, por lo que hay una gran cantidad de

from john import cleese 
from terry import jones, gilliam 

en mi código. Importaré módulos completos (como os o wx) si espero usar la mayor parte del módulo y el nombre del módulo es corto. También importaré módulos completos si hay un conflicto de nombres o si quiero recordarle al lector a qué se asocia esa función.

import michael 
import sarah 

import wave 

gov_speech = wave.open(sarah.palin.speechfile) 
parrot_sketch = wave.open(michael.palin.justresting) 

(Podría utilizar from wave import open as wave_open, pero calculo que wave.open será más familiar para el lector.

Answer 9

Usted puede estar interesado en desbordamiento de pila pregunta Why does 'import x;x.y' behave different from 'from x import y', and the first one fails when package x.init is not completed?.