> When creating new-style classes from within an extension module, the
> current behavior results in the __module__ attribute being set to the name
> of the Python module which first imports the extension module.
>
> I recall having a similar problem with my own extension classes in
> Boost.Python v1, but was a little surprised to find that it persists in
> Boost.Python v2, when creating new-style classes. A trivial inspection
> reveals this bit of code in typeobject.c:
>
> /* Set __module__ in the dict */
> if (PyDict_GetItemString(dict, "__module__") == NULL) {
> tmp = PyEval_GetGlobals();
> if (tmp != NULL) {
> tmp = PyDict_GetItemString(tmp, "__name__");
> if (tmp != NULL) {
> if (PyDict_SetItemString(dict, "__module__",
> tmp) < 0)
> return NULL;
> }
> }
> }
>
> I can work around this problem, but I wonder if it would be a good
> idea if Python set __name__ automatically during the import of an
> extension module? I realize that there are ways to undermine this,
> e.g. explicitly creating a nested module object.
The __name__ attribute is already set as soon as a module is created.
I think the problem is that the extension's dict is not the "current
globals dict" as returned by PyEval_GetGlobals().
There's no convenient way to make this so, since the "current globals
dict" is taken from the frame (and I don't want to change that).
What was your workaround?
I thought that the "correct" way to set __module__ is to use a dotted
name as the type name (the initializer for tp_name). Can you do that?
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4