[Python-Dev] pycache creation (original) (raw)

Steven D'Aprano steve at pearwood.info
Tue Mar 23 12:02:11 CET 2010

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

More information about the Python-Dev mailing list