On May 6, 2009, at 1:08 PM, Carl Witty wrote:

> On Wed, May 6, 2009 at 12:24 PM, Robert Bradshaw
> <[email protected]> wrote:
>> On May 6, 2009, at 11:18 AM, Carl Witty wrote:
>>
>>> On Wed, May 6, 2009 at 10:38 AM, Robert Bradshaw
>>> <[email protected]> wrote:
>>>> I already implemented this optimization, though only for cdef  
>>>> classes
>>>> within the same module. (If they're small enough, they may get even
>>>> inlined by the C compiler.) I'm not sure how possible this would be
>>>> to do across modules, but one difficulty is that the contents of
>>>> tp_new can change based on the .pyx file, not just the .pxd file.
>>>
>>> Really?  What in the .pyx file can change tp_new?  (I'm mostly just
>>> curious.)
>>
>> The __cinit__ (aka __new__) function, if any, get's invoked.
>
> So if we decided that the optimization was important enough, we could
> fix this by requiring that __cinit__ functions be declared in the .pxd
> file.
>
>>> Across modules, you should at least be able to call the tp_new
>>> function directly instead of going through the vtable.  (I assume  
>>> from
>>> the .pxd file you can at least determine the mangled name of the
>>> base's tp_new function?)
>>
>> This is the optimization I was referring too--look at the generated
>> sources for, e.g., sage.structure.element.pyx
>
> Yes, but you said that you only implement it within a single module
> (which is what I see in element.c); I'm saying that it should also be
> possible to implement across modules (just make tp_new functions
> non-static, add an extern declaration in the second module, and call
> the function directly).

Yes, I we could do this. We could also support exported cdef  
functions this way, instead of the current function import mechanism.  
(Or was there some reason it wasn't done this way in the first place?  
Certainly it results in "kinder" errors.)

- Robert


_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to