Guido van Rossum wrote:
On Mon, Mar 22, 2010 at 12:20 PM, Barry Warsaw <ba...@python.org> wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and deleting any byte-code files in the module/program directory.
Huh? Last time I looked weren't we going to make __pycache__ the
default (and eventually only) behavior?
I expect that the __pycache__ directories would quickly become the
recommended "defacto default" for writing and preinitializing modules and
packages, with the current behavior of having bytecode in the same
directory as the .py files only as the fall-back (what I meant by default)
behavior when the __pycache__ directories do not exist.
I see only two reasonable solutions for __pycache__ creation -- either
we change all setup/install scripts (both for core Python and for 3rd
party packages) to always create a __pycache__ subdirectory for every
directory (including package directories) installed; or we somehow
create it the first time it's needed.
>
But creating it as needed runs into at least similar problems with
ownership as creating .pyc files when first needed (if the parent
directory is root-owned a mere mortal can't create it at all).
>
So even apart from the security issue (which I haven't thought about deeply) I
think precreation should at least be an easily accessible option both
for the core (where it can be done by compileall) and for 3rd party
packages (where I guess it's up to distutils or whatever install
mechanism is used).
Yes, I think that is what Antoine was also getting at.
Is there a need for python to use __pycache__ directories 100% of the time?
For 2.x it seems like being flexible would be best, and if 3.x is going
to be strict about it, it should be strict sooner than later rather than
have a lot of 3rd party packages break at some point down the road.
Ron
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
