[Cython] weird declarations in fused types C code

mark florisson markflorisson88 at gmail.com
Fri May 11 13:00:16 CEST 2012

On 11 May 2012 11:54, mark florisson <markflorisson88 at gmail.com> wrote:
> 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