On Wed, Feb 6, 2013 at 4:26 AM, Thomas Heller firstname.lastname@example.org wrote:
I have become a fan of the new python 3.3 importlib in the last few days.
Glad it's working out for you!
It has allowed me to write a ModuleMapper which I put into sys.metapath (in sitecustomize.py, for Python 3.3).
This mapper currently does rename modules like 'Queue' or '_winreg' to the Python3 modules 'queue' or 'winreg' without the need to change my 2.7 sourcecode (changing the sourcecode is required when using six.moves to write 2.x/3.x compatible code).
The six.moves approach has another problem with freeze tools (py2exe for example): ModuleFinder does not find the moved modules because it cannot track __import__().
I have also started a new modulefinder which uses importlib to find modules; this was quite easy since I could copy a lot of code from importlib._bootstrap. The great thing is that this new modulefinder is much better than the old one: It finds modules in zipped eggs or other zip-archives which are on sys.path; also it finds the renamed modules correctly that my ModuleMapper has mapped.
The only thing that I am missing is that it is a bit of guesswork to find out the type of the module that importlib.find_loader() has found.
Previously imp.find_module returned a tuple containing the type of module found (like imp.PY_SOURCE), I have to poke around in some attributes of the result of importlib.find_loader() to guess the type.
You should be able to tell with an isinstance check on the returned loader and not have to look at any attributes (e.g. source will subclass SourceLoader, frozen will subclass FrozenImporter, etc.). If it continues to be an issue just let me know and we can see what we can do (this is obviously a niche need and so I would prefer not to change the loader API to explicitly accommodate this, but it can be done).