Hacking on the compiler in ways that break the frozen instance of importlib...
So, I'm currently trying to fix the regression in handling __class__ references in 3.3. The first step in this is unwinding the name change for the closure reference so it goes back to using "__class__" (instead of "@__class__") before finding a different way to fix #12370. As near as I can tell, my efforts are getting killed by the frozen instance of importlib: if I make the change in the straightforward fashion, the frozen copy of FindLoader.load_module() uses zero-argument super(), which tries to look up "@__class__", which fails, which means initialisation goes pear-shaped. I'm going to fix it in this case by tweaking importlib._bootstrap to avoid using zero-argument super() (with an unmodified core) before applying the changes, but yeah, be warned that you're in for some fun when tinkering with any construct used by importlib._bootstrap and end up doing something that involves changing the PYC magic number. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
2012/5/27 Nick Coghlan
So, I'm currently trying to fix the regression in handling __class__ references in 3.3. The first step in this is unwinding the name change for the closure reference so it goes back to using "__class__" (instead of "@__class__") before finding a different way to fix #12370.
As near as I can tell, my efforts are getting killed by the frozen instance of importlib: if I make the change in the straightforward fashion, the frozen copy of FindLoader.load_module() uses zero-argument super(), which tries to look up "@__class__", which fails, which means initialisation goes pear-shaped.
I'm going to fix it in this case by tweaking importlib._bootstrap to avoid using zero-argument super() (with an unmodified core) before applying the changes, but yeah, be warned that you're in for some fun when tinkering with any construct used by importlib._bootstrap and end up doing something that involves changing the PYC magic number.
Nasty! Perhaps freeze_importlib.py could be rewritten in C, so importlib could be recompiled when the compiler changes? -- Regards, Benjamin
Nasty! Perhaps freeze_importlib.py could be rewritten in C, so importlib could be recompiled when the compiler changes?
Or we support bootstrapping from the source file, e.g. with an environment variable BOOTSTRAP_PY which points to the _bootstrap.py source. Regards, Martin
On Sun, 27 May 2012 10:13:17 +0200 martin@v.loewis.de wrote:
Nasty! Perhaps freeze_importlib.py could be rewritten in C, so importlib could be recompiled when the compiler changes?
Or we support bootstrapping from the source file, e.g. with an environment variable BOOTSTRAP_PY which points to the _bootstrap.py source.
I've opened http://bugs.python.org/issue14928 and made it a release blocker. Regards Antoine.
Am 27.05.2012 09:43, schrieb Nick Coghlan:
So, I'm currently trying to fix the regression in handling __class__ references in 3.3. The first step in this is unwinding the name change for the closure reference so it goes back to using "__class__" (instead of "@__class__") before finding a different way to fix #12370.
As near as I can tell, my efforts are getting killed by the frozen instance of importlib: if I make the change in the straightforward fashion, the frozen copy of FindLoader.load_module() uses zero-argument super(), which tries to look up "@__class__", which fails, which means initialisation goes pear-shaped.
I'm going to fix it in this case by tweaking importlib._bootstrap to avoid using zero-argument super() (with an unmodified core) before applying the changes, but yeah, be warned that you're in for some fun when tinkering with any construct used by importlib._bootstrap and end up doing something that involves changing the PYC magic number.
I hate to say it, but: I told y'all so :) http://mail.python.org/pipermail/python-dev/2012-April/118790.html Georg
participants (5)
-
Antoine Pitrou -
Benjamin Peterson -
Georg Brandl -
martin＠v.loewis.de -
Nick Coghlan