[Cython] weird declarations in fused types C code
markflorisson88 at gmail.com
Fri May 11 12:44:55 CEST 2012
On 11 May 2012 07:38, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 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.
> 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.
> cython-devel mailing list
> cython-devel at python.org
More information about the cython-devel