¿Es seguro usar la opción -S de python?

La opción -S a python se define en la documentación como "Deshabilitar la importación del sitio del módulo y las manipulaciones dependientes del sitio de sys.path que conlleva". Descubrí que el inicio de Python en mi máquina es más del doble de rápido, a veces más más, cuando uso esta opción. Por ejemplo, en una máquina (lenta):¿Es seguro usar la opción -S de python?

$ time python -c 'print "hello"' 
hello 
python -c 'print "hello"' 0.14s user 0.03s system 85% cpu 0.204 total 

$ time python -Sc 'print "hello"' 
hello 
python -Sc 'print "hello"' 0.02s user 0.01s system 73% cpu 0.038 total

Eso es una aceleración de 5.3x. Y parece funcionar bien, al menos con los scripts que he probado. ¿Cuáles son las desventajas de usarlo?

Fuente

2012-07-03 apenwarr

Probablemente no sea una buena idea. Entre otras cosas, esto significa que el directorio site-packages no será añadido a la ruta, por lo que no será capaz de importar otra cosa que los módulos estándar: lib

python -Sc "import numpy" 
Traceback (most recent call last): 
    File "<string>", line 1, in <module> 
ImportError: No module named numpy

se puede ver en ti mismo site.py para ver lo que está haciendo Es solo un módulo en el directorio de la biblioteca normal. Al menos en mi sistema, parece que hace cuatro cosas principales:

establece el site-packages caminos
define la codificación por defecto
define un par de funciones de ayuda para uso interactivo (quit y help)
conjuntos de hasta sitio de personalización

específicos del usuario el primero de ellos es probablemente el más crítico, como se mencionó anteriormente. El segundo podría ser importante para hacer E/S de cadena dependiendo de la configuración regional de su sistema (es decir, puede obtener errores si la codificación predeterminada no está configurada correctamente). El tercero probablemente no sea tan importante. El último podría ser importante si desea tener personalizaciones de ruta por usuario (permitiendo que los usuarios tengan sus propios directorios de biblioteca personal, etc.).

Fuente

2012-07-03 19:57:00 BrenBarn

Hmm, parece que mi programa es solo en inglés (es decir, vago) y solo depende de módulos básicos básicos de python, * no * establecer la codificación predeterminada podría causar * menos * problemas (menos sorpresas con .lower() Y qué no). Así que esto podría estar bien cuando estoy escribiendo algunos scripts básicos que no hacen mucho, pero donde el tiempo de inicio importa. – apenwarr

que va a perder una gran parte de la ruta de búsqueda del módulo cuando se hace esto:

$ python -S 
Python 2.6.8 (unknown, Apr 19 2012, 01:24:00) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin 
>>> import sys 
>>> len(sys.path) 
9 

$ python 
Python 2.6.8 (unknown, Apr 19 2012, 01:24:00) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import sys 
>>> len(sys.path) 
26

Dependiendo de su sistema, que puede tener importantes consecuencias en cuanto a qué módulos están disponibles.

Otras cosas que pueden romperse son la configuración regional (establecida en el sistema predeterminado por site.py) y, en Windows, algunos códecs no estarán disponibles (tienen el alias de site.py).

Fuente

2012-07-03 19:57:10

Todo esto plantea la pregunta: ¿Por qué hay tantas cosas que se deben incluir en los paquetes del sitio? Estoy bastante seguro de que no es necesario la mayor parte del tiempo. Pero por alguna razón, es tradicional poner incluso código que puede usar una sola vez, en paquetes de sitio. Me parece que sería mejor colocar cosas que no son compartidas por múltiples aplicaciones bajo un único directorio en/usr/local o algo así. – user1277476

Porque ese es el lugar donde se supone que deben ir los módulos. En general, si instala una biblioteca de terceros, entra en el directorio de paquetes de sitios de python. ¿A dónde más deberían ir? – BrenBarn

Si se refiere a módulos que usted mismo crea para proyectos específicos, entonces sí, está bien no ponerlos en paquetes de sitio. Pero cuando instala una biblioteca de terceros, generalmente debe ir en paquetes de sitio, porque si instala alguna biblioteca, probablemente signifique que la usará para cosas. Buscando en mi directorio de paquetes de sitio, veo muchas bibliotecas de propósito general como numpy, scipy, matplotlib, gtk, pygame, pyparsing dabo --- cosas que muchos programas de Python podrían necesitar. – BrenBarn

La bandera -S hace lo siguiente:

no implican 'sitio de importación' en la inicialización

Esto significa que el módulo de site no se importa durante la inicialización de Python. Una breve descripción es que este módulo "agregará rutas específicas del sitio a la ruta de búsqueda del módulo y agregará algunas direcciones internas". No hacer todo este trabajo hará que la puesta en marcha sea más rápida.

Utilización de la documentación como guía, las -S resultados de bandera en:

No hay módulos adicionales añadidos a sys.path.Puede comparar la diferencia comenzando python y python -S y haciendo lo siguiente en ambos import sys; print sys.path. Muchos módulos no estarán disponibles, por lo que no podrá importarlos.
El código de inicialización del sitio personalizado no se ejecutará (esto se puede definir en un módulo llamado sitecustomize).
El código de inicialización personalizado no se ejecutará (esto se puede definir en un módulo llamado usercustomize).

La respuesta breve a su pregunta es: sí, hace que el inicio de Python sea más rápido, pero muchos módulos y códigos de personalización no estarán disponibles ni serán posibles.

Si importa principalmente sus propios módulos y escribe sus propios cómputos/códigos, entonces la bandera -S está bien. Pero si tiene una instalación de Python con módulos instalados en diferentes lugares, entonces no podrá usarlos con el indicador -S.

Fuente

2012-07-03 19:58:13

¿Es seguro usar la opción -S de python?

Respuesta

Cuestiones relacionadas