[Pyrex] possible bug with public function declarations

[Robby Dermody]

Greg Ewing wrote:

> And the Py_DECREF is only because the method you're calling
> returns a Python type. If it returned a C type you wouldn't
> even have that.
>
> I do appreciate the desire to be able to separately
> compile parts of a single module, however. I don't have
> any philosophical objection to that, I just haven't put
> a lot of thought into how to support it cleanly. Maybe in
> a future version.
>
> Thanks for your comments,
>
I tried to make the modifications to put my stuff in as extension types. 
Most of it would be fine, but I had some design issues pop up that made 
me put this move off until later, either when I'm forced to make such a 
change :), or pyrex begins to support such a feature, as you said.

An issue that I had is that some of my code is what some would call 
"utility functions". I have a few modules full of these utility 
functions. Requiring that one instantiate an object to get at a 
miscellaneous set of utility functions is somewhat unwieldy (as AFAIK, 
pyrex doesn't support class methods). Another issue is with C callbacks. 
Libraries like glib oftentimes operate with callbacks, and these 
functions need to fit a specific signature. From what I could tell, I 
would have to take such a callback function out of the extension type 
and have it sitting in the file on the top level for this to work. Just 
some common use cases we might want to think about when/if this issue is 
given more thought...

In any case, I would be very interested in helping out and lending 
thoughts if you do decide to sit down and think this future feature 
though. Thanks for keeping an open mind.

Robby