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).">

(original) (raw)




On Wed, Feb 6, 2013 at 4:26 AM, Thomas Heller <theller@ctypes.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).