Roundup Robot added the comment:
New changeset b5b81a3eb6e6 by Brett Cannon in branch '3.4':
Issue #20884: Don't assume in importlib.__init__ that __file__ is
http://hg.python.org/cpython/rev/b5b81a3eb6e6
New changeset 42ae7b2524a2 by Brett Cannon in branch 'default':
Merge for issue #20884
Changes by Brett Cannon br...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Jurko Gospodnetić added the comment:
Thanks Brett! :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list mailing
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
stage: - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Nick Coghlan added the comment:
Issue 20942 now covers the spurious value in _frozen_importlib.__file__,
leaving this free to cover the fact that importlib/__init__.py doesn't support
freezing in 3.4.0.
--
priority: deferred blocker - normal
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Larry Hastings added the comment:
So is this fixed? Can we close the issue? I'm tagging 3.4.0 final soon.
--
nosy: +larry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Nick Coghlan added the comment:
Status update:
- Brett added the porting note to What's New for 3.4.0 final.
- the fact importlib.__init__ can't currently be frozen due to the incidental
use of __file__ is now just a bug to be fixed in 0.4.1, and fixing that will be
the trigger for closing
Roundup Robot added the comment:
New changeset b626f4978a28 by Brett Cannon in branch 'default':
Issue #20884: whatsnew: Frozen modules don't set __file__ anymore.
http://hg.python.org/cpython/rev/b626f4978a28
--
nosy: +python-dev
___
Python tracker
Brett Cannon added the comment:
Step 1 was just checked in.
Step 2: Jurko can you see if the uploaded patch fixes things for you?
--
assignee: - brett.cannon
keywords: +patch
Added file: http://bugs.python.org/file34416/frozen_file.diff
___
Python
Jurko Gospodnetić added the comment:
Step 2: Jurko can you see if the uploaded patch fixes things for you?
Yup. That's exactly how we were working around the issue before
reporting it here. :-)
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
OK, that sounds reasonable. That means I think we need to:
1. add an explicit porting note to the What's New for 3.4.0 final about frozen
modules no longer defining __file__
2. fix importlib.__init__ to tolerate freezing again in 3.4.1
3. remove
Brett Cannon added the comment:
I assume you mean for 3. to fix PyImport_ImportFrozenModuleObject() and not
stop resetting __file__ for _frozen_importlib in importlib.__init__ like we are
currently doing. I think you're right that it could wait until 3.5 as it will
only be apparent to people
Jurko Gospodnetić added the comment:
As mentioned by Anthony Tuininga at:
https://bitbucket.org/anthony_tuininga/cx_freeze/issue/61/python-340-nameerror-name-__file__-is-not#comment-9077661
The value of __file__ in the problematic importlib/__init__.py
module with Python 3.3. is 'frozen'
Nick Coghlan added the comment:
Hmm, I think we still have something weird going on:
$ python3
Python 3.3.2 (default, Nov 8 2013, 13:38:57)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux
Type help, copyright, credits or license for more information.
import _frozen_importlib
Jurko Gospodnetić added the comment:
Ask per Nick's instructions I tweaked cx_Freeze to import a dummy
package as frozen. The dummy package has the following structure:
gugu/
__init__.py
and its __init__.py file contains only the 8 bytes '__file__'
(does not include the quotes).
Then
R. David Murray added the comment:
Depending on what cx_Freeze is doing with packages, I wnder if this What's New
3.4 porting note is relevant:
* Frozen packages no longer set ``__path__`` to a list containing the package
name, they now set it to an empty list. The previous behavior could
Jurko Gospodnetić added the comment:
That 'what's new' item seems relevant, except that the issue here
is related to the __file__ attribute instead of __path__. Could it
be that the same fix actually updated how the __file__ attribute is
defined as well?
The bug seems to be caused by
Jurko Gospodnetić added the comment:
This could possibly also have been caused by a resolution to issue 18088
(http://bugs.python.org/issue18088).
See commit e873f2e67353 (http://hg.python.org/cpython/rev/e873f2e67353).
--
___
Python tracker
Thomas Kluyver added the comment:
I think msg213138 has the key: importlib is actually getting frozen in the
Python sense of the module's bytecode being included in a C file and then
compiled, not just copied into a zip file. When we freeze importlib._bootstrap
as _frozen_importlib, importlib
Brett Cannon added the comment:
I found the problem. _frozen_importlib is being loaded by C code which is using
the equivalent of _imp.init_frozen(). importlib.machinery.FrozenImporter is
doing a more controlled, manual approach of using _imp.get_frozen_object() and
then initializing the
Jurko Gospodnetić added the comment:
+1 for the clean solution :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list
Thomas Kluyver added the comment:
In the clean solution, it sounds like making importlib/__init__.py deal with
the lack of a __file__ attribute would fix the problem in cx_Freeze. We'd still
need to work out whether freezing importlib into the base executable is the
right thing to do, but
Nick Coghlan added the comment:
I'm not sure Brett's plan is such a great idea. If you look at the file
attributes in my demo above, they include a leading path element (based on
the executable location), so it *is* possible to use the pkgutil data
access APIs sensibly from a frozen module (and
Brett Cannon added the comment:
On Mar 12, 2014 6:04 PM, Nick Coghlan rep...@bugs.python.org wrote:
Nick Coghlan added the comment:
I'm not sure Brett's plan is such a great idea. If you look at the file
attributes in my demo above, they include a leading path element (based on
the
Nick Coghlan added the comment:
Reading
https://bitbucket.org/anthony_tuininga/cx_freeze/src/default/cx_Freeze/finder.py
I have a suspicion that the import system reimplementation in there is going
to need updates to handle PEP 451 (I suspect there are even latent defects in
relation to
Nick Coghlan added the comment:
Another relevant link: http://docs.python.org/3.4/reference/import.html
Just to clarify the reason for the pending status:
At the moment, I suspect this is a matter of either 3.4 revealing a latent
defect in the cx-freeze import emulation (by being less
Jurko Gospodnetić added the comment:
Here's a recipe I can use to reproduce the problem on my PC.
Environment:
* Windows 7 SP1 x64
* Python 3.4.0rc3
* cx_Freeze checkout from its current HEAD
* repository: https://bitbucket.org/anthony_tuininga/cx_freeze
* HEAD commit:
New submission from Jurko Gospodnetić:
Python 3.4 introduced a change to Lib/importlib/__init__.py that added the
following code to it:
else:
# importlib._bootstrap is the built-in import, ensure we don't create
# a second copy of the module.
_bootstrap.__name__ =
R. David Murray added the comment:
So you aren't running into problems with issue 20778? (That issue exists in
3.3 as well).
--
nosy: +brett.cannon, eric.snow, r.david.murray
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
Not having __file__ defined is an odd issue as importlib.__init__ always comes
from a file in CPython. I have no issue making the setting of the attribute
conditional, though.
--
___
Python tracker
Jurko Gospodnetić added the comment:
David: Nope, the issue does not exist with 3.3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
Python-bugs-list mailing
Ned Deily added the comment:
I hope this can be resolved before the 3.4 final release or it will not be
possible to use cxFreeze with Python 3.4 without additional workarounds in
cxFreeze.
It's too late for this to go into 3.4.0 unless someone can make a really good
case to the release
Nick Coghlan added the comment:
It's at least a deferred blocker, and that's my instinct as to the right
setting (especially since we're assuming that 3.4.1 will happen a month or so
after the PyCon US sprints).
I'll dig into a bit more to see if I can provoke the misbehaviour (e.g. we may
Jurko Gospodnetić added the comment:
I'll try to set up and post a reproducible use case tomorrow. Then you can
decide. It could turn out that the use case we ran into has an easy workaround.
--
___
Python tracker rep...@bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: normal - deferred blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20884
___
___
37 matches
Mail list logo
