Not-quite-the-module-name qualified names in extension modules? What?

[Alf P. Steinbach /Usenet]

Hi.

I built the [xxmodule.c] from the source distribution, as suggested by the
Python 3.1.1 docs. I named this [xx.pyd], as I believed the module name was just
"xx". Indeed importing xx works fine, but when I do help(xx) I get ...


Help on module xx:

NAME
xx - This is a template module just for instruction.

FILE
c:\projects\progrock\lib\progrock\cppy_dev\examples\02_xx_apilevel\xx.pyd

CLASSES
builtins.Exception(builtins.BaseException)
error
builtins.object
xxmodule.Null
builtins.str(builtins.object)
xxmodule.Str

class Null(builtins.object)
| Methods defined here:
|
</example>


.... with the name "xxmodule" somehow in there as qualification.

Checking the standard "csv" module I similarly get ...


<example>
CLASSES
builtins.Exception(builtins.BaseException)
_csv.Error
builtins.object
Dialect
excel
excel_tab
DictReader
DictWriter
Sniffer
</example>


.... with the name "_csv" in there.

And I'm pretty sure that these not-quite-the-module-name names stem from the
literal specification of names in the C code in the extension module, assuming
that the csv module is indeed a C extension module.

Is it really necessary to qualify names in the C code?

And can it do harm when such name qualification is not using the final module
name but instead something like "xxmodule" or "_csv"?

More to the point, what's the point?


Cheers,

- Alf