[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: At some point this was fixed in importlib. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: Did this go anywhere, David? Since beta2 just went out now is the time to either revert or enshrine the new behavior. -- ___ Python tracker ___ _

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

R. David Murray added the comment: Well, the problem with asking me what the right thing to do is that I think the old behavior of just using the default os umask makes the most sense. I think we should figure out who made the original change in behavior and ask them what the right thing is to

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: Turns out the failure is because I have simply been opening bytecode files for writing using _io.FileIO(..., 'w') which just uses the OS's default permissions. Guess that won't cut it anymore. =) So does this mean I am expected to chmod the bytecode file to hav

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: OK, I need a double-check here, David. At this point I have narrowed it down to this code triggering it:: finder = importlib._bootstrap._PyPycFileFinder('.') sys.path_importer_cache['.'] = finder And I am not kidding, that assignment is required. I might be

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: So removing the built-in, frozen, and extension importers did not stop the bug from happening. Calling importlib._bootstrap._PyFileFinder directly does not trigger the bug, even when trying with a finder for '.' first. And having sys.path be only '.' for filein

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Changes by Brett Cannon : Removed file: http://bugs.python.org/file14527/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: On Mon, Jul 20, 2009 at 16:25, R. David Murray wrote: > > R. David Murray added the comment: > > Oh, a bit of clarification: the call that creates the pyc file in both > the "normal" case and the error case is a call to the normal import > command (or __import__

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

R. David Murray added the comment: Oh, a bit of clarification: the call that creates the pyc file in both the "normal" case and the error case is a call to the normal import command (or __import__ in the test case). The call to import_module is a prereq to producing the bug, but it doesn't matte

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

R. David Murray added the comment: If you have a .py file with permissions r--r--r-- and you import it, the pyc file will (in 2.6+ and 3.x) have permissions r--r--r--. However, if '.' is in the path and import_module has been used, the file will instead have permissions rw--r--r-- (assuming the

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

Brett Cannon added the comment: import_module are implemented completely differently between 2.6 and 3.1, so the difference is not surprising. As for the permission stuff, the files are simply created using open(..., 'wb') so it has everything to do with what the system default for the execu

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

R. David Murray added the comment: Test case. -- keywords: +patch Added file: http://bugs.python.org/file14526/issue6526-test.diff ___ Python tracker ___

[issue6526] importlib.import_module affects permissions of .pyc files subsequently created by import

New submission from R. David Murray : In debugging an intermittent test failure we discovered that if '.' is in the path and import_module is called, then what happens when __import__ causes the creation of a .pyc file changes. Without the forgoing, the permissions of the .py file are copied to