Because I don't have access to Windows, importlib doesn't check the Windows registry for paths to search (see the use of _PyWin_FindRegisteredModule() in Python/import.c and its definition in PC/import_nt.c).

I am considering this a release blocker as once importlib is bootstrapped in this will be a regression that Windows users may not be happy with.

Yeah, that's one part of imp.find_module that I kind of set aside too (the #ifdef MS_COREDLL sections in Python/import.c).  For now would it be sufficient to expose _PyWin_FindRegisteredModule() privately with a wrapper in the imp module?

You could just expose it, but on Windows I believe all extension modules are builtins, so you should be able to properly use _winreg to get at the registry and thus not require keeping the C code around.

But that's just a guess.

FYI, I just deleted PC/import_nt.c as it stopped compiling after my removal of _imp.get_suffixes(). Obviously hg has the history of the file so if someone needs to resurrect it there shouldn't be much issue.

Brett (and/or Brian?), this sounds like it should be tackled soon, to give Windows users enough time of testing 3.3.

OTOH, I don't want it to block beta1.

Yes, it should be tackled soon, but I lack Windows access so I can't do the work myself. Basically no one seems to use or care about this feature so it might die "on the vine" if someone doesn't step forward.

I will take a look at it shortly...was too busy with installer/path issues and then PEP 397 last week.

Moving back to blocker for beta2.

Ping. Brian?  I'd rather have some testing period for this, so I'm reluctant to release b2 without it.

Sorry, I've been too busy to get caught up with this. I'm away most of today but I can try to take a look tonight.

Can someone tell me where you want this changed? I guess Lib/imp.py in the find_module function, based on previous mention of imp.find_module? That's shown as deprecated so I'm hesitant to start there.

I don't really know anything about importlib, especially not enough to know where to start. If I have a pointer to the right spot I'll make the registry searching a part of it.

So it should end up in Lib/importlib/_bootstrap.py since it is directly part of how import works. The original code as found in Python 3.2 for PyWin_FindRegisteredModule() is referenced in Python/import.c and is implemented in PC/import_nt.c. You will want to create a new sys.meta_path importer (if I'm reading the code from Python/import.c correctly in terms of the call to PyWin_FindRegisteredModule() happening before sys.path is traversed). You can refactor FileFinder if you need to in order to reuse its code.

In terms of working with importlib, you will probably need the winreg module, so inject that (see _setup() on how to do that). Also remember that while this is Python code, you will need to rebuild to trigger the regeneration of importlib.h. Otherwise (I hope) it isn't too complicated or hard to understand.

I don't have Windows, but here is an example of a WindowsRegistryImporter, written outside importlib (the script also contains a fake implementation of winreg, so I could test it...)

Of course it needs to be rewritten to fit in _bootstrap.py;  at least the script shows that it's only necessary to implement a find_module() function.

I'm not sure I had all details right - for example, should we search for the full module name, or only the last component?

This loader has some interesting features; for example it's possible to have several modules in the same .pyd file, as long as it exports the various PyInit_* functions.

I'm not sure what the deal is but I can't get the changes to apply (fitting Amaury's patch into _boostrap.py), meaning nothing I change to the _boostrap.py file changes how anything operates.

I don't have much time to learn all of this stuff and make it work on Windows like the build process does on Linux, especially not with a release waiting for it. I'd just say to run without it until someone who needs it has time to fiddle around.

importlib.h is not rebuilt on Windows, see issue15431.

I just wanted to say that Amaury's proof-of-concept looks right (although what is returned by the registry isn't a "fullname" but a file path so I would at least change that variable name and you wouldn't append this mat path finder but instead insert it before PathFinder).

And to answer the question of what to pass in, technically it's the tail part of the name for full backwards-compatibility, but that's stupid as it creates an ambiguity e.g. a package named foo vs. a submodule named pkg.foo, so I say use the full name of the module when looking something up in the registry.

Brian, perhaps the problem described in issue15431 ("Cannot build importlib.h on Windows") is part of the problem for you here.

I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

So I tried to make proper changes in _bootstrap.py, and regenerate importlib.h on Linux.
I don't have any Windows machine; all this is completely untested, but at least it can help some Windows developer to finish the work, and write unit tests...
(in case of bugs, if you don't know how to regenerate importlib.h, it's still possible to monkeypatch the WindowsRegistryImporter class; it's in sys.meta_path)

> I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

At worse, perhaps 3.3 can be released without this feature. I don't know who relies on it.

pywin32 used to install modules this way, but it seems it doesn't anymore:
http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/file/16707e6f1624/pywin32_postinstall.py#l307
    # It is possible people with old versions installed with still have 
    # pywintypes and pythoncom registered.  We no longer need this, and stale
    # entries hurt us.
Maybe this feature is not so important after all.

> I would really like to release beta2 this weekend.  Is it possible to get this resolved by then?

As others stated, I'm not sure it's entirely necessary. Given the two dependencies that need to be fixed before this one can move forward, I don't think it's happening soon so I'd suggest to move on with beta2.

OK, demoting.

New changeset bd58c421057c by Martin v. Löwis in branch 'default':
Issue #14578: Support modules registered in the Windows registry again.
http://hg.python.org/cpython/rev/bd58c421057c

Amaury's patch nearly worked; committed with slight modifications.