¿Debo usar numpy (o pylab) como un entorno de Python utilizando `from numpy import *`?

Utilizo pylab (más específicamente numpy) en todos mis progtwigs de python. Las excepciones son muy raras, si las hay. Hasta ahora, he tomado el hábito de importar números de la siguiente manera:

from numpy import * 

Esto tiene la ventaja de hacer que parezca que numpy fue parte de Python desde el principio. ¿Hay algo malo en el hecho de importar números como este en cada script? Quiero decir, aparte del hecho de que cada script / progtwig requerirá un poco más de memoria y llevará más tiempo para cargar.

Creo que tener que escribir numpy o incluso np antes de cada llamada de función que proviene de numpy (por ejemplo, np.zeros(3) ) es tedioso porque me obliga a saber qué función proviene de numpy y cuál no. Realmente no me importa que la función de ceros provenga de numpy o python, solo quiero / necesito usarla.

¿Qué notación es mejor según usted?

  1. Usar from numpy import * cambia el comportamiento de any , all y sum . Por ejemplo,

     any([[False]]) # True all([[True, False], [False, False]]) # True sum([[1,2],[3,4]], 1) # TypeError: unsupported operand type(s) for +: 'int' and 'list' 

    Mientras que, si usas from numpy import * , los valores son completamente diferentes:

     from numpy import * any([[False]]) # False all([[True, False], [False, False]]) # False sum([[1,2],[3,4]], 1) array([3, 7]) 

    El conjunto completo de colisiones de nombres se puede encontrar de esta manera (gracias a @Joe Kington y @jolvi por señalar esto):

     import numpy as np np_locals = set(np.__all__) builtins = set(dir(__builtins__)) print([name for name in np_locals.intersection(builtins) if not name.startswith('__')]) # ['any', 'all', 'sum'] 
  2. Esto puede llevar a errores muy confusos, ya que alguien que está probando o usando su código en un intérprete de Python sin from numpy import * puede ver un comportamiento completamente diferente al que usted ve.

  3. El uso de múltiples importaciones del formulario from module import * puede complicar el problema con más colisiones de este tipo. Si eliminas este mal hábito, nunca tendrás que preocuparte por este error (potencialmente confuso).

    El orden de las importaciones también podría importar si ambos módulos redefinen el mismo nombre.

    Y hace que sea difícil averiguar de dónde provienen las funciones y los valores.

  4. Si bien es posible usar from numpy import * y seguir accediendo a las incorporaciones de Python, es incómodo:

     from numpy import * any([[False]]) __builtins__.any([[False]]) 

    y menos legible que:

     import numpy as np np.any([[False]]) any([[False]]) 
  5. Como dice el zen de Python,

    Los espacios de nombres son una gran idea, ¡usemos más!

Mi consejo sería nunca usar from module import * en cualquier script, punto.

Solo para explicar lo que otras personas han dicho, numpy es un módulo especialmente malo para usar import * con.

pylab es para uso interactivo, y está bien allí. Nadie quiere escribir pylab.zeros una y otra vez en una shell cuando solo podrían escribir zeros . Sin embargo, tan pronto como empiezas a escribir código, todo cambia. Lo está escribiendo una vez y es posible que permanezca cerca para siempre, y otras personas (por ejemplo, usted mismo un año en el futuro) probablemente intentarán averiguar qué diablos estaba haciendo.

Además de lo que @unutbu ya dijo sobre anular la sum integrada de python, float int , etc, y lo que todos han dicho sobre no saber de dónde proviene una función, numpy y pylab son espacios de nombres muy grandes.

numpy tiene 566 funciones, variables, clases, etc. dentro de su espacio de nombres. ¡Eso es mucho! pylab tiene 930 ! (Y con Pylab, estos vienen de varios módulos diferentes).

Claro, es bastante fácil adivinar de dónde son los zeros o ones zeros , pero ¿qué hay de source o DataSource o lib.utils ? (todo esto estará en su espacio de nombres local si lo hace from numpy import *

Si tiene un proyecto incluso un poco más grande, existe la posibilidad de que tenga una variable local o una variable en otro archivo que tenga un nombre similar a algo en un módulo grande como numpy . De repente, ¡empieza a preocuparse mucho más por lo que está llamando exactamente!

Como otro ejemplo, ¿cómo distinguiría entre la función fft pylab y el módulo fft numpy ?

Dependiendo de si lo haces

 from numpy import * from pylab import * 

o:

 from pylab import * from numpy import * 

fft es una cosa completamente diferente con un comportamiento completamente diferente! (Es decir, intentar llamar a fft en el segundo caso generará un error).

En general, siempre debe evitar la from module import * , pero es una idea especialmente mala en el caso de numpy , scipy , et. Alabama. porque son espacios de nombres tan grandes.

Por supuesto, todo lo que se ha dicho, si solo estás buscando en una concha tratando de obtener rápidamente un gráfico de algunos datos antes de pasar a hacer algo con él, entonces usa pylab . Para eso está ahí. ¡Simplemente no escriba algo de esa manera para que alguien intente leer más adelante en el futuro!

no es un problema importante si numpy es el único módulo que importa de esta manera. Nunca NUNCA importe ningún otro módulo como este en sus scripts (a menos que usted haya escrito ese módulo y sepa todo sobre él y sea razonablemente pequeño. Por ejemplo, a veces divide un módulo en dos archivos para que pueda compartimentar mejor).

Regla general: la legibilidad de su código no se verá afectada significativamente al importar módulos de uso generalizado (como numpy) de esta manera. Pero nunca nunca importes más de uno.

Mi regla: NUNCA hago este tipo de importación. Siempre hago algo como “importar número como np” si se va a usar mucho.

Yo diría que es una ventaja saber de dónde proviene cada llamada de función. Te da más control sobre lo que está en tu espacio de nombres y evita todo tipo de conflictos potenciales que serán un dolor de depurar. Si cree que import numpy as np es tedioso, solo espere hasta que tenga un módulo de terceros que redefine el nombre de una función y tenga que rastrear algún comportamiento misterioso que no estaba anticipando.

Vamos a abordar desde el otro lado, obtengo su código para depurar, y veo que llama:

 zeros(5) 

es tedioso revisar su fuente para ver si es np.zeros o si lo ha redefinido en otra parte, y como Pylab tiene 930 nombres, esto puede suceder fácilmente.