Collin Winter wrote:
While working with Subversion's python API bindings this morning, I discovered a function in one of their modules illegally named "import" (svn.client.import, for the curious). Because the extension module in question is written in C, the interpreter doesn't flag the otherwise-illegal identifier "import" at compile-time; if you try to call the function at runtime, however, the interpreter raises a SyntaxError, since svn.client.import is an illegal name.
There is still a way to call the function, though, through
import_ = svn.client.__dict__['import'] import_()
My question is this: is there any interest in preventing situations like this by including checks in Python/modsupport.c:Py_InitModule4 to make sure that the PyMethodDef contains only valid identifiers, or is this a case of "if it hurts when you do that, don't do that"?
I cannot see a "complete" solution, i.e. one that works for all types, all methods and attribute names of all types, and so on. There might not even be a way to determine all identifiers that some module wants to support, other than by inspecting the source code.
Also, this is not a frequently-reported problem: if people find they cannot call a certain method, they just rename the function and be done. If nobody detects that a function is not callable, then the function is possible just useless.
If this is a SWIG-generated module, I would see a bug in SWIG here: SWIG should know what the Python keywords are, and rename all functions following some pattern (traditionally, suffixing an underscore).