Martin v. Löwis wrote:
>> Exactly. How would you define where the pyr folder goes? At the root
>> of a package? What if I delete the __init__.py file there? Will the
>> existing pyr folder be orphaned and a new one created in each
>> subfolder? Unlike VCS working copies, the package / module / script
>> hierarchy is not formally defined in python.
>
> The module name could guide the location. If you are importing
> xml.dom.minidom, it could put the pyc file into a sibling of the pyc
> folder for xml (under the name xml.dom.minidom.<label>).
>
> If you then remove __init__, you are no longer able to import xml.dom,
> but you might import dom.minidom (assuming you put the xml folder into
> sys.path). Then, a new pyc file would be created in the pyc folder for
> the dom package.
I see three possible logical locations for the Python cache directories:
1. In each directory containing Python source files.
Major Pro: easy to keep source files associated with their cached versions
Major Con: proliferation of cache directories
2. In each top level directory on sys.path, flat file structure
Major Pro: trivial to separate out all cached files
Major Con: for path locations like the top of the standard lib, the
cache directory would get a *lot* of entries
3. In each top level directory on sys.path, shadow file heirarchy
Major Pro: trivial to separate out all cached files
Major Con: ??? (I got nuthin')
I didn't list a single global cache directory as a viable option as it
would create some nasty naming conflicts due to runs with different
sys.path entries and would make it impossible to create zipfiles with
precached bytecode files.
Note that with option two, creating a bytecode only zipfile would be
trivial: just add the __pycache__ directory as the top-level directory
in the zipfile and leave out everything else (assume there were no data
files in the package that were still needed).
Packages would still be identifiable by the existence of the cached pyc
file for their __init__modules.
Going back to my previous example (with one extra source file to show
how a top-level module would be handled), scheme 2 would give:
module.py
package/
__init__.py
foo.py
subpackage/
__init__.py
bar.py
__pycache__/
module.cpython-27.pyc
module.cpython-27.pyo
package.__init__.cpython-27.pyc
package.__init__.cpython-27.pyo
package.foo.cpython-27.pyc
package.foo.cpython-27.pyo
package.subpackage.__init__.cpython-27.pyc
package.subpackage.__init__.cpython-27.pyo
package.subpackage.bar.cpython-27.pyc
package.subpackage.bar.cpython-27.pyo
While scheme 3 would look like:
module.py
package/
__init__.py
foo.py
subpackage/
__init__.py
bar.py
__pycache__/
module.cpython-27.pyc
module.cpython-27.pyo
package/
__init__.cpython-27.pyc
__init__.cpython-27.pyo
foo.cpython-27.pyc
foo.cpython-27.pyo
subpackage/
__init__.cpython-27.pyc
__init__.cpython-27.pyo
bar.cpython-27.pyc
bar.cpython-27.pyo
For comparison, here is what it would look like under scheme 1:
module.py
package/
__init__.py
foo.py
subpackage/
__init__.py
bar.py
__pycache__/
__init__.cpython-27.pyc
__init__.cpython-27.pyo
bar.cpython-27.pyc
bar.cpython-27.pyo
__pycache__/
__init__.cpython-27.pyc
__init__.cpython-27.pyo
foo.cpython-27.pyc
foo.cpython-27.pyo
__pycache__/
module.cpython-27.pyc
module.cpython-27.pyo
And the initial version proposed in the PEP:
module.py
module.pyr/
cpython-27.pyc
cpython-27.pyo
package/
__init__.py
__init__.pyr/
cpython-27.pyc
cpython-27.pyo
foo.py
foo.pyr/
cpython-27.pyc
cpython-27.pyo
subpackage/
__init__.py
__init__.pyr/
cpython-27.pyc
cpython-27.pyo
bar.py
bar.pyr/
cpython-27.pyc
cpython-27.pyo
My major concern with scheme 2 is the possibility of directory size
limits affecting the caching of files, but scheme 3 looks pretty good to
me (with the higher level cache linked to the directory that is actually
on sys.path, the cache locations aren't as arbitrary as I originally
feared).
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
