[Python-Dev] __pycache__ creation

Ron Adam rrr at ronadam.com
Tue Mar 23 02:03:30 CET 2010


Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 12:20 PM, Barry Warsaw <barry at 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



More information about the Python-Dev mailing list