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


<example>
     >>> help( xx )
     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

-- 
blog at <url: http://alfps.wordpress.com>