¿Es posible que Python guarde los archivos .pyc en una ubicación de carpeta separada que esté en sys.path?¿Cómo se compilaron los archivos python en una carpeta separada?
/code
foo.py
foo.pyc
bar.py
bar.pyc
Para:
/code
foo.py
bar.py
/code_compiled
foo.pyc
bar.pyc
me gustaría esto porque siento que sería más organizado. Gracias por cualquier ayuda que me puedan dar.
Hay PEP 304: Controlling Generation of Bytecode Files. Su estado es Withdrawn y el correspondiente patch 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. Los archivos *.pyc se pueden usar tal cual o empaquetados en un huevo.
actualización: [PYC Repository Directories] (http://www.python.org/dev/peps/pep-3147/) – jfs
Puede editar su respuesta con algo útil sobre la actualización. –
Err. Ver más abajo. La respuesta corta no es de ninguna manera, excepto la realmente hacky en Python 2.x; trivial en Python 3.2 y posterior. –
"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.
> ¿Por qué? Aparentemente porque hacen que la salida de ls o la lista de archivos de Windows Explorer estén más desordenados. Una preocupación subjetiva pero bastante legítima, ¿no? – Maleev
@Maleev: "visualmente abarrotado"? Explorer se puede ordenar por tipo de archivo para colocar los archivos .pyc en otro lugar. Linux 'ls' se puede usar con un comodín (es decir,' ls * .py').Tratar de reorganizar los archivos es una gran pérdida de tiempo cuando se trata de formas triviales de reducir el desorden visual. –
Mover la ubicación del archivo .pyc no es lo mismo que desactivar la característica. Tampoco hacerlo hace que el intérprete de Python sea más complejo. El argumento presentado se basa en un malentendido de lo que realmente es un caché (un recurso de almacenamiento temporal diseñado para mejorar la localidad de referencia). Los cachés son, por definición, tanto con pérdida como localizados. El despliegue de archivos .pyc en la jerarquía de un proyecto Python frustra el propósito de un caché. En el mejor de los casos, puede decir que es una optimización a costa de la higiene de la jerarquía de archivos. –
Estoy de acuerdo, distribuir tu código como un huevo es una gran 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.
No estoy de acuerdo. 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. Éstos son algunos de ellos (todos ellos me he encontrado en un momento u otro):
Existen soluciones provisionales para todos estos problemas, PERO en su mayoría son soluciones provisionales NO.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.
Si usted está dispuesto a sacrificar la generación de código de bytes en total para él, hay una marca de línea de comandos:
python -B file_that_imports_others.py
se puede acoplar a build/preferencias de ejecución del IDE
No es pep en curso que enable building bytecode to magic directory .
Básicamente, todos los archivos python se compilarán en el directorio __pythoncache__.
Como 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 en el que tiene Archivos Python, y contendrá archivos .pyc para cada versión de Python utilizada en las fuentes)
En los días oscuros y antiguos de 2003, PEP 304 se lanzó para 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 se levantó 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ó a los waring Unladen Swallow y el 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, observe el mymodule.__cached__ del módulo para el nombre del archivo pyc y analícelo con imp.get_tag(). Ver the What's New section para más información.
TL; DR - Solo funciona en Python 3.2 y superior. Los hacks pobres sustituyen a las versiones anteriores.
PEP 3147 es solo una solución parcial. Los directorios '__pycache__' todavía desordenan el código fuente. La principal molestia para mí con pycs es que los directorios quedan sin recuperar después de 'svn switch' o tal. – Suor
Parece un problema estético: el .pyc almacenado en caché solo se utilizará para las coincidencias de marca de tiempo exactas; probablemente de filecmp.filecmp (shallow = True). Aunque no es bello, no se deben usar cachés adicionales. –
Pray decir que, como la mayoría de las cosas en 3.2, esto también se incluyó en 2.7? – ArtOfWarfare
¿Cómo intentó Python 3.2? Implementa los directorios de repositorio PEP 3147: PYC (http://www.python.org/dev/peps/pep-3147/). –
Si no le importan los archivos .pyc, puede usar 'os.system ('del * .pyc')' (ventanas, por ejemplo) al final de su script. – Charlie