Hi,
I think maybe I've seen this brought up once or twice before in the
past, but with no real discussion. There is a slightly unpythonic
problem with using cpdef inline functions defined in a .pxd file that
happen to access global variables. For example:
$ cat foo.pxd
FOO_A = 1
cpdef inline foo():
return FOO_A
$ cat bar.pyx
from foo cimport foo
print(foo())
Running this like python -c 'import bar' results in:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "bar.pyx", line 3, in init bar
print(foo())
File "foo.pxd", line 4, in foo.foo
return FOO_A
NameError: name 'FOO_A' is not defined
Of course, if the function "foo" were not inlined this would work
fine. But the inlining really breaks things, I think, in an
unpythonic way. I could be misunderstanding how Cython's "inline"
should be interpreted but I feel like it's an implementation detail
that should not fundamentally change how the code in that function
works.
There are a couple issues here. First of all, if a .pxd file exists
but not a .pyx, no actual module will be created. This is by design
of course, but in this case either, inlined functions in a .pxd module
should be prohibited from accessing globals, or a trivial module
should be created to store the globals for that module.
The second problem boils down to the global variable lookup being
compiled to something like:
__pyx_t_1 = __Pyx_GetModuleGlobalName(__pyx_n_s_FOO_A)
Perhaps, when a function from one module gets inlined in another
module, at least in the case where it needs to access globals, the
originating module should be imported first and
__Pyx_GetModuleGlobalName replaced with an equivalent that uses the
originating module's globals.
So have a global variable like
static PyObject* __pyx_d_foo
and in the module init code something like:
_pyx_t_1 = __Pyx_Import("foo")
__pyx_d_foo = PyModule_GetDict(__pyx_t_1)
then in the inlined function, replace the call to
__Pyx_GetModuleGlobalName to an equivalent that uses __pyx_d_foo
instead of __pyx_d.
This all assumes, of course, that "foo" is an importable module. I'm
not sure this makes sense otherwise... If not then maybe inlining a
function should also "inline" any global variables it uses.
Thoughts?
Erik
