[Python-Dev] __pycache__ creation

[Steven D'Aprano]

On Tue, 23 Mar 2010 07:38:42 am Guido van Rossum wrote:
> 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).

Isn't that a feature though?

I don't see why this is a problem, perhaps somebody can explain what I'm 
missing.

Current system:
If the user doesn't have write permission in the appropriate directory, 
no .pyc file is created and the import uses the .py file only.

New system (proposal):
If the user doesn't have write permission in the appropriate directory, 
no __pycache__ folder is created and the import uses the .py file only. 
If the user has write permission and the __pycache__ folder is created, 
but the umask is screwy and no .pyc files can be created, no .pyc file 
is created and the import uses the .py file only despite the existence 
of an empty __pycache__ folder.

Why bother to delete the unwritable __pycache__ directory? If you can't 
write to it, neither can any process with the same or fewer 
permissions. If some other process has more permissions, it could write 
something nasty to the directory, but surely it's not Python's 
responsibility to be secure in the face of a compromised root or admin 
account?

As I see it, the only question is, should we warn the user that we can't 
write to the newly-created __pycache__ directory? I'm +0 on that. To be 
clear:

Can't create __pycache__? That's a feature. Fail silently and fall back 
to using the .py file alone.

Existing __pycache__ directory, but can't write to it? That's a feature 
too, treat it just like the above.

No __pycache__ directory, and creating it succeeds, but then import 
can't write to the freshly created directory? That's just weird, so I'm 
+0 on raising a warning and -1 on raising an exception.


-- 
Steven D'Aprano