[Cython] problem with PySequenceMethods in Py3k

[Stefan Behnel]

Hi Lisandro,

Lisandro Dalcin wrote:
> compiling (c) extsetslice ... ok
> extsetslice.cpp:316: error: invalid conversion from 'int
> (*)(PyObject*, Py_ssize_t, Py_ssize_t, PyObject*)' to 'void*'
> 
> Apparently, in "PySequenceMethods", the "sq_slice" and "sq_ass_slice"
> slots changed to be typed "void*" and their names prefixed with
> "was_". I bet this change intended to provide backward compatibility
> in the struct layout. IMHO, this was a really bad idea, people porting
> extension modules to Py3k will not notice the change unless they give
> a try with C++.

Yes, I'm pretty sure that slipped through. There was a point during the
development of Py3k up to which they intended to keep the C-API compatible,
and afterwards they turned to really fixing it up for the future language.
Looks like this change went in before that and didn't get fixed later on.


> Those "was_sq_[ass_]slice" are just ignored in Py3k, and then I assume
> the Cython-generated code could not work as expected...

I'm fine with a warning from Cython that this will no longer work in Py3,
and a preprocessor #if that puts 0 into the method struct in that case. We
should just disable that test case for Py3. The 'new' slicing API works in
all Python versions that Cython supports, so old code should be fixed
instead of trying to find a work-around in Cython. A warning will help
people to do the right thing.


> I bet you never noticed the warning, just because the C++ compilation
> is usually contaminated with the warning about -Wstrict-prototypes not
> being a valid flag in C++ ;-) ... Can you see why I hate so much to
> have warnings that we can avoid... At some point, I'll try to hot-fix
> that stupid -Wstrict-prototypes for the C++ case...

Yes, I think everybody noticed this by now. :)

It's because Python itself was built with that option, and it passes its
CFLAGS on to the extensions. I never got around to looking for a fix
either. I'd say this needs fixing in distutils.

Another problem with the C++ tests is that the doctests do not run on the
C++ compiled modules, as the C compiled modules with the same name were
already imported. But that's a minor issue IMHO, as the compilation is the
thing that matters here.

Stefan