gestion - interprete de python
¿Cómo se compilan los archivos python en una carpeta separada? (8)
¿Es posible que Python guarde los archivos .pyc en una ubicación de carpeta separada que esté en sys.path ?
/code
foo.py
foo.pyc
bar.py
bar.pyc
A:
/code
foo.py
bar.py
/code_compiled
foo.pyc
bar.pyc
Me gustaría esto porque creo que sería más organizado. Gracias por cualquier ayuda que me puedan dar.
"Siento que sería más organizado" ¿Por qué? ¿Cómo? ¿Qué está tratando de lograr?
El objetivo de guardar la salida del compilador es ahorrar un poco de tiempo de carga cuando se importa el módulo. ¿Por qué hacer esto más complejo? Si no te gustan los .pyc''s, ejecuta un script "delete all the .pyc''s" periódicamente.
No son esenciales; son útiles. ¿Por qué desactivar esa ayuda?
Esto no es C, C ++ o Java donde los objetos resultantes son esenciales. Esto es solo un caché que Python usa. Los marcamos como "ignorados" en Subversion para que no se envíen accidentalmente.
Estoy de acuerdo, distribuir tu código como un huevo es una excelente manera de mantenerlo organizado. ¿Qué podría ser más organizado que un solo archivo que contiene todos los códigos y metadatos que alguna vez necesitarías? Cambiar la forma en que funciona el compilador de códigos de bytes solo causará confusión.
Si realmente no te gusta la ubicación de esos archivos pyc, una alternativa es ejecutar desde una carpeta de solo lectura. Como Python no podrá escribir, nunca se crearán archivos pyc. El golpe que se toma es que cada archivo de Python tendrá que volver a compilarse tan pronto como se cargue, independientemente de si lo ha cambiado o no. Eso significa que su tiempo de puesta en marcha será mucho peor.
Hay PEP 304: control de la generación de archivos de código de bytes . Su estado es Withdrawn y el parche correspondiente rechazado. Por lo tanto, puede que no haya una forma directa de hacerlo.
Si no necesita el código fuente, puede eliminar los archivos *.py . *.pyc archivos *.pyc se pueden usar tal cual o empaquetados en un huevo.
Si está dispuesto a sacrificar la generación de bytecode para ello, hay un indicador de línea de comando:
python -B file_that_imports_others.py
Se puede poner en las preferencias de compilación / ejecución de IDE
Estoy en desacuerdo. Las razones son incorrectas o al menos no están bien formuladas; pero la dirección es válida. Hay buenas razones para poder segregar el código fuente de los objetos compilados. Aquí hay algunos de ellos (todos con los que me he encontrado en un momento u otro):
- dispositivo incorporado leyendo una ROM, pero capaz de usar un sistema de archivos en memoria en la RAM.
- multi-os dev environment significa compartir (con samba / nfs / whatever) mi directorio de trabajo y construir en múltiples plataformas.
- empresa comercial desea distribuir pyc solo para proteger el IP
- ejecute fácilmente el conjunto de pruebas para múltiples versiones de python utilizando el mismo directorio de trabajo
- más fácil de limpiar archivos de transición (rm -rf $ OBJECT_DIR en lugar de encontrar. -name ''* .pyc'' -exec rm -f {} /;)
Existen soluciones provisionales para todos estos problemas, PERO en su mayoría son soluciones temporales, NO soluciones. La solución adecuada en la mayoría de estos casos sería que el software acepte una ubicación alternativa para almacenar y buscar estos archivos de transición.
Hay un impulso continuo que permitirá construir bytecode en el directorio mágico .
Básicamente, todos los archivos de Python se compilarán en el directorio __pythoncache__ .
Desde Python 3.2 se ha implementado PEP 3147 : esto significa que todos los archivos .pyc se generan dentro de un directorio __ pycache__ (habrá un directorio __ pycache para cada directorio donde tenga archivos Python, y contendrá archivos .pyc para cada versión de Python utilizada en las fuentes)
En la oscuridad y los días antiguos de 2003, PEP 304 salió a desafiar este problema. Su parche fue encontrado deficiente. Las dependencias de la plataforma variable del entorno y los sesgos de la versión la hicieron trizas y dejaron sus bits diseminados por los páramos.
Después de años de sufrimiento, un nuevo rival surgió en los últimos días de 2009. Barry Warsaw convocó al PEP 3147 y lo envió a la batalla, empuñando un arma simple con habilidad. El PEP aplastó los archivos de PYC abarrotados, silenció al guardia de Unladen Swallow y al intérprete de CPython cada uno tratando de argumentar que su archivo PYC debería ser triunfante, y permitió que Python descansara tranquilamente con sus fantasmas muertos ocasionalmente corriendo en la oscuridad de la noche. PEP 3147 fue encontrado digno por el dictador y fue nombrado caballero en los papeles oficiales en los días de 3.2.
A partir de 3.2, Python almacena los archivos PYC de un módulo en __pycache__ en el directorio del módulo. Cada archivo PYC contiene el nombre y la versión del intérprete, por ejemplo, __pycache__/foo.cpython-33.pyc . También puede tener un __pycache__/foo.cpython-32.pyc compilado por una versión anterior de Python. La magia correcta ocurre: la correcta se usa y recompila si no está sincronizada con el código fuente. En tiempo de ejecución, mire el modulo del módulo mymodule.__cached__ para el nombre del archivo pyc y imp.get_tag() con imp.get_tag() . Consulte la sección Novedades para obtener más información.
TL; DR: solo funciona en Python 3.2 y superior. Los hacks pobres sustituyen a las versiones anteriores.