Brett Cannon added the comment:
At some point this was fixed in importlib.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6526
___
Brett Cannon br...@python.org 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 rep...@bugs.python.org
http://bugs.python.org/issue6526
Brett Cannon br...@python.org 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
R. David Murray rdmur...@bitdance.com 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
Brett Cannon br...@python.org 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
Changes by Brett Cannon br...@python.org:
Removed file: http://bugs.python.org/file14527/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6526
___
Brett Cannon br...@python.org 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
New submission from R. David Murray rdmur...@bitdance.com:
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
R. David Murray rdmur...@bitdance.com added the comment:
Test case.
--
keywords: +patch
Added file: http://bugs.python.org/file14526/issue6526-test.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6526
Brett Cannon br...@python.org 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
R. David Murray rdmur...@bitdance.com 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
R. David Murray rdmur...@bitdance.com 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,
Brett Cannon br...@python.org added the comment:
On Mon, Jul 20, 2009 at 16:25, R. David Murray rep...@bugs.python.orgwrote:
R. David Murray rdmur...@bitdance.com 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
13 matches
Mail list logo
