[Cython] problematic code in C++ pyregr tests

Stefan Behnel stefan_ml at behnel.de
Sun Jul 31 10:53:00 CEST 2011


I noticed a couple of problems in the latest pyregr test run for py3k.


1) test_contextlib.cpp:16926: warning: deprecated conversion from string 
constant to ‘char*’

This repeated warning refers (I assume) to each literal in this code:

char* __pyx_import_star_type_names[] = {

This looks like a standard C++ WTF to me. I noticed that Lisandro keeps 
casting string literals in his code, so I wonder if that's something we 
need to do here as well?

2) test_cgi.cpp:2494: error: ‘None’ was not declared in this scope

There seems to be a problem with the dict-loop optimisation. This is how 
the following code gets translated:

  *     for k, v in dict(form).items():             # <<<<<<<<<<<<<<

   __pyx_t_1 = None;
   __pyx_t_5 = 0;
   __pyx_t_6 = PyDict_Size(__pyx_t_1);
   while (1) {
     /* __pyx_t_7 allocated */
     /* __pyx_t_8 allocated */
     if (unlikely(__pyx_t_6 != PyDict_Size(__pyx_t_1))) {
       PyErr_SetString(PyExc_RuntimeError, "dictionary changed size during 
iteration"); {__pyx_filename = __pyx_f[0]; __pyx_lineno = 114;

Looks like the literal doesn't get evaluated. I'll look into this.

3) warning: TestClassUtilityCode:18:10: 'cpdef_method' redeclared
warning: TestClassUtilityCode:29:10: 'cpdef_cname_method' redeclared

4) test_pep263.cpp:520: error: redefinition of ‘PyObject* __pyx_kp_b_1’
test_pep263.cpp:519: error: ‘PyObject* __pyx_kp_b_1’ previously declared here
test_pep263.cpp:526: error: redefinition of ‘PyObject* __pyx_kp_b_2’
test_pep263.cpp:525: error: ‘PyObject* __pyx_kp_b_2’ previously declared here

Triggered by this code, which refers to the same byte string literals twice 
in both cases:

  *         self.assertEqual(             # <<<<<<<<<<<<<<
  *             "".encode("utf-8"),
  *             b'\xd0\x9f\xd0\xb8\xd1\x82\xd0\xbe\xd0\xbd'
   /* __pyx_t_1 allocated */
   __pyx_t_1 = PyObject_GetAttr(__pyx_v_self, __pyx_n_s__assertEqual); if 
(unlikely(!__pyx_t_1)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 9; 
__pyx_clineno = __LINE__; goto __pyx_L1_error;}
   /* __pyx_t_2 allocated */
   __pyx_t_2 = PyTuple_New(2); if (unlikely(!__pyx_t_2)) {__pyx_filename = 
__pyx_f[0]; __pyx_lineno = 9; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
   __Pyx_GOTREF(((PyObject *)__pyx_t_2));
   __Pyx_INCREF(((PyObject *)__pyx_kp_b_1));
   PyTuple_SET_ITEM(__pyx_t_2, 0, ((PyObject *)__pyx_kp_b_1));
   __Pyx_GIVEREF(((PyObject *)__pyx_kp_b_1));
   __Pyx_INCREF(((PyObject *)__pyx_kp_b_1));
   PyTuple_SET_ITEM(__pyx_t_2, 1, ((PyObject *)__pyx_kp_b_1));
   __Pyx_GIVEREF(((PyObject *)__pyx_kp_b_1));

  *         self.assertEqual(             # <<<<<<<<<<<<<<
  *             "\".encode("utf-8"),
  *             b'\\\xd0\x9f'
   /* __pyx_t_3 allocated */
   __pyx_t_3 = PyObject_GetAttr(__pyx_v_self, __pyx_n_s__assertEqual); if 
(unlikely(!__pyx_t_3)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 13; 
__pyx_clineno = __LINE__; goto __pyx_L1_error;}
   /* __pyx_t_2 allocated */
   __pyx_t_2 = PyTuple_New(2); if (unlikely(!__pyx_t_2)) {__pyx_filename = 
__pyx_f[0]; __pyx_lineno = 13; __pyx_clineno = __LINE__; goto __pyx_L1_error;}
   __Pyx_GOTREF(((PyObject *)__pyx_t_2));
   __Pyx_INCREF(((PyObject *)__pyx_kp_b_2));
   PyTuple_SET_ITEM(__pyx_t_2, 0, ((PyObject *)__pyx_kp_b_2));
   __Pyx_GIVEREF(((PyObject *)__pyx_kp_b_2));
   __Pyx_INCREF(((PyObject *)__pyx_kp_b_2));
   PyTuple_SET_ITEM(__pyx_t_2, 1, ((PyObject *)__pyx_kp_b_2));
   __Pyx_GIVEREF(((PyObject *)__pyx_kp_b_2));

5) there are also several compiler crashes in that log

6) several tests bail out with

File "runtests.py", line 900, in run_test
     except (unittest.SkipTest, support.ResourceDenied):
AttributeError: 'module' object has no attribute 'ResourceDenied'

I guess that's an incompatibility of our test runner with the latest Py3k.

7) g++: /.../workspace/BUILD/pyregr/cpp/test_inspect.o: No such file or 
g++: no input files

There are loads of these - not sure what might trigger them.

As I said, I'll look into the dict looping bug. If any of the other bugs is 
obvious to someone and not too hard to fix, it would be nice to get it done 
for the release. However, I think none of them is a real blocker.


More information about the cython-devel mailing list