[Pyrex] [Cython-dev] Cython 0.9.6.7 released

[Robert Bradshaw]

On Oct 11, 2007, at 5:12 AM, Gustavo Sverzut Barbieri wrote:

> On 10/11/07, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> This release is completely independent from the recent Pyrex release
>> (though we are working on merging those changes). The highlights are:
>>
>> - GIL handling code
>
> Will we use GIL or "gil"? It would be great to keep compatibility with
> Pyrex here to avoid confusion. But if we rename it's better to have
> the same behavior too.

I believe we use GIL, and ours is a function attribute. This will be  
changed for compatibility with Pyrex. (What is included is the first  
version of a patch that subsequently underwent much revision before  
getting applied to Pyrex, but as we are looking at merging Pyrex  
changes soon we figured we'd do that all at once.

>> - support of keyword-only arguments
>> - Class-level executable bodies for cdef classes, including a working
>> classmethod()
>> - RichCmp instead of Cmp for <, <=, ==, ... operators (for
>> consistency with interpreted python)
>> - interned integer constants
>> - several bug fixes (of which there is some overlap with the recent
>> Pyrex release) and optimizations.
>
> I don't see one change that I submitted to Pyrex and was included in
> their release 0.9.6, it's about checking the return of tp->new() for
> NULL (exceptions generated in __new__())
>
> http://lists.copyleft.no/pipermail/pyrex/2007-May/002327.html
>
> but you may check if Greg applied as-is or if he did some other  
> checks there.

Yes. Some patches I saw were part of Pyrex I opted (for the sake of  
getting this release out of the door) to merge in when we merged in  
the new Pyrex release.

On that note, to make sure bug fixes don't fall through the cracks  
it's a good idea to post them (and a fix :-) at https://launchpad.net/ 
cython .

>> There is also a new experimental type of function, rdef (formerly
>> cdef overridable, but the syntax is still up for debate), which is a
>> cdef function which is callable from python (via an auto-generated
>> def function) and can be overriden in pure-python subclasses.
>
> I haven't tried it or looked at the generated code, but AFAIU the file
> where rdef is defined will always use the C version and not this
> overriden pure-python subclasses. That's the case? If so, what's the
> point in this? (use case)

Yes, it always calls the c version, to maximize speed. However, there  
is some trickery at the top of the c function to decide (very  
quickly) whether or not the function in question has been overridden  
in python, and if so calls the python version instead. Thus it  
behaves like a def function in terms of visibility and  
overrideability, but avoids all the python calling semantics overhead  
calling from c to c when it's not overridden.

> Last thing: why did you removed callable() as a known built-in?

I think this was because people might want to pass it around as a  
python object (is that right Stefan?). Eventually we will have the  
same (very nice trick) as Pyrex where it returns a c function that  
can also be coerced into a python object, and will re-instate  
callable (as well as others).

> (http://www.cython.org/hg/cython/rev/28a5fc848c53) Do you plan to add
> it back? How about getattr()?
>    I know getattr is not being used due the C version using 2
> parameters while the python version uses 3, we can have our
> Cython_Getattr() as a static inline function that does the check or
> add one more element to builtin_functions tuple to check for number of
> provided parameters or change this tuple by an object that could have
> its methods overriden and in this case it will just work.

This is a good idea.

>
> -- 
> Gustavo Sverzut Barbieri
> --------------------------------------
> Jabber: barbieri at gmail.com
>    MSN: barbieri at gmail.com
>   ICQ#: 17249123
>  Skype: gsbarbieri
> Mobile: +55 (81) 9927 0010