inspect.getmodulename giving unexpected results

[Geoff Bache]

Hi all,

I'm trying to examine some things in my stack. The information I get
out of inspect.stack() gives file names and I would like to convert
them to module names. I naturally assumes inspect.getmodulename would
fix this for me.

Unfortunately, it doesn't seem to do that in some cases. Consider the
following code:

## file 'inspect_test'

#!/usr/bin/env python

import logging, inspect

print inspect.getmodulename(logging.__file__),
inspect.getmodulename(__file__)

I hoped that this would print
logging __main__

or at least
logging inspect_test

but instead it prints
__init__ None

which isn't very helpful, although it could technically be considered
correct (I can go to the 'logging' directory and type "import
__init__" but nobody ever does)

I guess I was hoping to get the names of the modules as they appear in
sys.modules. Maybe there is some other way to do that? I can naturally
write my own method to do this but wondered if I'm missing something
here.

Regards,
Geoff Bache

 

[Thomas Jollans]

Hi all,

I'm trying to examine some things in my stack. The information I get
out of inspect.stack() gives file names and I would like to convert
them to module names. I naturally assumes inspect.getmodulename would
fix this for me.

Unfortunately, it doesn't seem to do that in some cases. Consider the
following code:

It does behave as documented: it does not find package names, or investigate
sys.modules

## file 'inspect_test'

rename this file to "inspect_test.py", and the filename will make sense to
inspect.getmodulename, which should *then* return "inspect_test" instead of
None.

#!/usr/bin/env python

import logging, inspect

print inspect.getmodulename(logging.__file__),
inspect.getmodulename(__file__)

I hoped that this would print
logging __main__

or at least
logging inspect_test

but instead it prints
__init__ None

which isn't very helpful, although it could technically be considered
correct (I can go to the 'logging' directory and type "import
__init__" but nobody ever does)

I guess I was hoping to get the names of the modules as they appear in
sys.modules. Maybe there is some other way to do that? I can naturally
write my own method to do this but wondered if I'm missing something
here.

Not that I know of.

 

[Geoff Bache]

It does behave as documented: it does not find package names, or investigate
sys.modules

Possibly, although for me "logging" is exposed as a module, and ought
to behave as one when requesting the module name. The fact that it's a
package internally doesn't seem relevant to me in this context. It's
weird to me that when I do

import os, logging

treating these things as normal modules I can get the right name for
"os" but get "__init__" when requesting "logging". Externally, these
things appear to be the same. I can accept from the docs that if I did
"getmodulename" on "logging.config" I would get "config" back.

rename this file to "inspect_test.py", and the filename will make sense to
inspect.getmodulename, which should *then* return "inspect_test" instead of
None.

I realise that, but of course I can't do that in the real code. It's a
long-established convention to drop the ".py" from executable programs
on UNIX.

Regards,
Geoff

 

[Thomas Jollans]

Possibly, although for me "logging" is exposed as a module, and ought
to behave as one when requesting the module name. The fact that it's a
package internally doesn't seem relevant to me in this context. It's
weird to me that when I do

import os, logging

treating these things as normal modules I can get the right name for
"os" but get "__init__" when requesting "logging". Externally, these
things appear to be the same. I can accept from the docs that if I did
"getmodulename" on "logging.config" I would get "config" back.


I realise that, but of course I can't do that in the real code. It's a
long-established convention to drop the ".py" from executable programs
on UNIX.

Then again, it's a classic trick to put your Python code in ../site-packages/
(or the like) and just put a tiny stub script in bin/ for projects of the same
kind of dimensions where anybody would care about the executable having a file
extension or not ;-)