[Pyrex] possible bug with public function declarations

[Robby Dermody]

Greg Ewing wrote:

> Robby Dermody wrote:
>
>>
>> I'm thinking there may be a possible bug with public C function
>> declarations in Pyrex 0.93.
>>
>> The project is set up so that foo.pyx and bar.pyx are linked together,
>
>
> Linking two Pyrex-generated modules together isn't
> really supported, and strange things might happen if
> you try it. You might get away with it if one of them
> restricts itself to C-only declarations and operations,
> but Pythonish things are likely to go haywire.

The issue that I had is that I have a whole bunch of C code I am 
expressing in pyrex, and putting it all in a single .pyx file would be 
unrealistic and cumbersome. I split it across multiple .pyx files, and 
end up building them all and linking them together into a single shared 
object library. Strange things did in fact happen with python code in 
these modules, but I fixed that by calling the other .pyx file's init 
methods manually when the main .pyx file (which has the same name as the 
library created) is initialized. This module provides a python interface 
into the rest of the system -- which is mostly C functions with python 
code here and there. Everything except exception propagation seems to 
work without a hitch, and C functions in separate modules can call each 
other without a problem, as long as they are public and the external 
declarations (.pxi) are imported.

It's a shame these .pxi files are depreciated. As I use pyrex 
(incorrectly, I guess :) it was the "best" way to do things that allowed 
me to both modularize the code and keep as much python API out of the C 
function calls as possible for speed reasons. But see below...

>
> All the .pxi stuff is pretty much deprecated now. A
> better way to make cross-pyx C calls is to make them
> C methods of an extension type. (Directly calling
> top-level C functions of another module isn't supported
> yet, but may be in a future version.)
>
hmm...I might do that. The primary module would create an instance of 
each other module's extension type. The thing that might make this 
somewhat unwieldy is that I would have to pass around pythonic object 
references to code that needs to make these calls, and I assume that 
there would be extra speed penalties incurred for making function calls 
through the extension type.

You aren't that far off from pyrex being able to directly call top level 
C functions of other modules in a manner that doesn't require the coder 
manually writing some magic, but .pxi files (that properly state each 
function's signature, including the 'except' component) seem an 
essential part of that. Past that, all one really needs to do is link 
each of the modules together as a single extension, delegate a primary 
module with the same name as the library produced, and have that module 
call each other module's init routine when it is imported by external 
python code. Of course, this is in my experience with Pyrex, which is 
_quite_ limited compared to yours. :)

Robby