[Cython] Dev days status

[Robert Bradshaw]

On Jun 17, 2008, at 4:54 AM, Stefan Behnel wrote:

> Robert Bradshaw <robertwb at ...> writes:
>> On Jun 16, 2008, at 11:23 PM, Stefan Behnel wrote:
>>> One thing I'd add is an optimisation for normal object-returning
>>> functions
>>> that do not have a return statement, i.e. that do not really return
>>> anything
>>> but exceptions. Here, we could change the signature internally to
>>> returning a
>>> bint instead (normal return or exception), which avoids the INCREF/
>>> DECREF None
>>> overhead for the return value.
>>
>> That is a good idea, though might mess up the signature (e.g. for
>> cdef methods that may be overridden).
>
> It would be fine for functions, though, and that's where I'd expect  
> the
> biggest impact anyway, e.g. when inlining short functions.

Very good point.

>>>> - Using the .pyx file for "cimport" when a .pxd file is unavailable
>>>> (basically auto-generation of pxd files).
>>>
>>> I'm not so sure about that one. This basically means cimporting
>>> from .pyx
>>> files, which might really lead to a performance drop of the
>>> compiler (remember
>>> that the slowest thing is still the scanner).
>>
>> I imagine we would want to cache this, perhaps in an easier to parse
>> format that .pxds are now (as parsing them can take a while too).
>
> Like a pickled .pxd parse tree? That might obviously change over  
> Cython
> versions, but if it's only for caching...

Yep. Note that I've looked into this and these can be huge (at least  
once a bit of analysis is done).

>>>> These last two have the disadvantage that the dependancy tree could
>>>> become much more connected, so we would provide a way to disable
>>>> them.
>>
>> There are several ways it becomes tighter. First, one can import
>> rather than cimport when one doesn't need speed and doesn't want to
>> create a compile-time dependancy (e.g. like in a huge project like
>> Sage). Secondly, everything in the file gets cimported, not just the
>> interface exposed by the .pxd.
>
> I actually think a lot of stuff would never be cimported, think of  
> the Python
> stdlib, for example. I mean, we may still see the day where C  
> extensions in
> the stdlib ship with .pxd's, but until then...

Yeah. I think this is mostly for ease of use of users--having to  
write .pxd's and .pyx's is natural for people coming from the C side  
of things, but not at all for those coming from Python.

>> Thirdly, any time the .pyx file
>> changes, it needs to be checked (instead of only on .pxd changes).
>
> True, and that means tracking and parsing all included .pxi files.  
> I actually
> think that was the reason why .pxd files were introduced in the  
> first place.
> Importing from .pyx files might not be that a good idea after all...


If pxd files are around, only they would be used. This is only if  
they're not around.

- Robert