[Cython] weird declarations in fused types C code

mark florisson markflorisson88 at gmail.com
Fri May 11 12:54:50 CEST 2012

On 11 May 2012 11:44, mark florisson <markflorisson88 at gmail.com> wrote:
> On 11 May 2012 07:38, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Hi,
>> while trying to replace the "import sys; if sys.version_info >= (3,0)" in
>> the fused types dispatch code by the more straight forward "if
>> PY_MAJOR_VERSION >= 3" (before I came to think that this particular case
>> only guards useless code that does the wrong thing),
> Yes, you made that plenty clear, sorry for thinking in terms of python
> code. For the record, it does do the right thing.
>> I noticed that the
>> code generates a declaration of PyErr_Clear() into the outside environment.
>> When used in cdef classes, this leads to an external method being declared
>> in the class, essentially like this:
>>    cdef class MyClass:
>>        cdef extern from *:
>>            void PyErr_Clear()
>> Surprisingly enough, this actually works. Cython assigns the real C-API
>> function pointer to it during type initialisation and even calls the
>> function directly (instead of going through the vtab) when used. A rather
>> curious feature that I would never had thought of.
> Yes, normally the parser catches that.
>> Anyway, this side effect is obviously a bug in the fused types dispatch,
>> but I don't have a good idea on how to fix it. I'm sure Mark put some
>> thought into this while trying hard to make it work and just didn't notice
>> the impact on type namespaces.
> I am aware of this behaviour, the thing is that the dispatcher
> function needs to be analyzed in the right context in order to
> generate an appropriate function or method in case of a cdef class
> (which are different from methods in normal classes even when
> synthesized). I thought about splitting the declarations from the
> actual function, and analyzing that in the module scope. Perhaps with
> some name mangling this can avoid names being accidentally available
> in user code. I don't recall if I have tried that already, but I'll
> give it another try.

Ah, I see I already split them, all that is needed is to put it in the
global scope now :)

>> I've put up a pull request to remove the Py3 specialisation code, but this
>> is worth some more consideration.
> Looks good to me, I'll merge it.
>> Stefan
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel

More information about the cython-devel mailing list