homepage

$ ./python -Wdefault
Python 3.3.0b1 (default:8bf691d0b004+, Jul 15 2012, 23:20:06) 
[GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pkgutil
>>> list(pkgutil.walk_packages("."))
/home/ncoghlan/devel/py3k/Lib/inspect.py:453: DeprecationWarning: inspect.getmoduleinfo() is deprecated
 info = getmoduleinfo(path)
/home/ncoghlan/devel/py3k/Lib/inspect.py:445: DeprecationWarning: imp.get_suffixes() is deprecated; use the constants defined on importlib.machinery instead
 for suffix, mode, mtype in imp.get_suffixes()]
[(FileFinder('.'), 'foo', False), (FileFinder('.'), 'python-gdb', False), (FileFinder('.'), 'setup', False)]
The problem is the calls to inspect.getmodulename().
Do these APIs really need to be deprecated? Can't they just be redirected to importlib instead?

I think the imp functions do need to go away. They perpetuate an absolutely horrendous API that I'm trying to slowly kill (and the underlying imp code is already reusing importlib). They already are a burden for future API growth as people already rely on imp.find_module() and imp.load_module() in such a way that untangling is right pain.

New changeset af7961e1c362 by Nick Coghlan in branch 'default':
Close #15387: inspect.getmodulename() now uses a new importlib.machinery.all_suffixes() API rather than the deprecated inspect.getmoduleinfo()
http://hg.python.org/cpython/rev/af7961e1c362 

The problem turned out to just be inspect.getmodulename() still relying on the deprecated inspect.getmoduleinfo(), so I changed it to be based on importlib.machinery instead.
I did make an importlib API addition to do it though - the all_suffixes() function dynamically adds together all the suffixes relevant for the current process so it will pick up any modification post import, while still allowing code that doesn't care about module types to ignore the details of the different kinds.

RE: the API addition: fine by me if it makes your life easier.