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.
+---------------------------------------------------------------+
David Abrahams
C++ Booster (http://www.boost.org) O__ ==
Pythonista (http://www.python.org) c/ /'_ ==
resume: http://users.rcn.com/abrahams/resume.html (*) \(*) ==
email: david.abrahams@rcn.com
+---------------------------------------------------------------+
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