[issue17222] py_compile.compile() explicitly sets st_mode for written files

Brett Cannon report at bugs.python.org
Mon Feb 18 20:02:17 CET 2013


Brett Cannon added the comment:

So py_compile always replaced the file, even in Python 3.3: http://hg.python.org/cpython/file/79ea59b394bf/Lib/py_compile.py#l141 (this is why I changed the title of the bug). What did change, though, is that py_compile now writes bytecode files just as import does, which means copying the file permissions of the source file for the bytecode file. E.g. if you listed the permissions for test.py in your example output I bet it's -rw-r----- just like what /dev/null ended up with.

I'm not going to change this as this is very much on purpose for security reasons; it's more of a long-standing bug that py_compile never used the proper permissions than it is changing the semantics to what they are today. Since py_compile is for compiling and writing out source code it should match what import does (if you are doing this to verify the file will parse properly, which is what writing to /dev/null suggests, it would be more accurate to just pass the raw source code through the AST module and make sure no exceptions are raised, else just write into the /tmp directory and let the OS clean up).

What I will do, though, it document this fact in the docs with a "Changed in Python 3.4" note and in What's New since people should be aware of it.

----------
assignee:  -> brett.cannon
components: +Documentation
keywords: +easy
priority: high -> normal
stage:  -> needs patch
title: py_compile.compile() replaces target files, breaking special files and symlinks -> py_compile.compile() explicitly sets st_mode for written files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17222>
_______________________________________


More information about the Python-bugs-list mailing list