[Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib... (original) (raw)
Benjamin Peterson benjamin at python.org
Sun May 27 09:50:25 CEST 2012
- Previous message: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
- Next message: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2012/5/27 Nick Coghlan <ncoghlan at gmail.com>:
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.loadmodule() 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
- Previous message: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
- Next message: [Python-Dev] Hacking on the compiler in ways that break the frozen instance of importlib...
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]