> On AIX, building a shared library for use by extension modules and > which uses the Python 'C' API is way harder than it should be**; the > best workaround we could find involves hijacking > _PyImport_LoadDynamicModule to load the shared library and patch up > the symbol references. > > _PyImportLoadDynamicModule is undocumented, AFAICT. Am I not > supposed to touch it? Is it likely to disappear or change its > signature? That's anybody's guess. I have no plans in this area, but it's only an external symbol because we wanted a logical separation between importdl.c and import.c. If someone has a great idea for refactoring this that involves changing its signature, I don't see why not. Now, maybe you're right that this *should* be documented and guaranteed API -- we've promoted internal APIs to that status before without removing the leading underscore (e.g. _PyString_Resize). > On a related note, I wonder about all of the _[A-Z] names in > Python. I know that at least in C++, these names are reserved to the > compiler implementation. I assume the same holds for 'C', and wonder > if Python's use of these names is intentional, on the "to be changed > someday" list, or something else. They're reserved by standard C too, but I figure we'd be safe by using _Py as the prefix. Same thing really as assuming ASCII or 8-bit bytes -- standard C doesn't guarantee those either. --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