Mailman 3 November 2011 - cython-devel

PEP 380 approved: syntax for generator delegation
by Stefan Behnel March 6, 2012

March 6, 2012

Hi, PEP 380 ("yield from") recently went through the approval gate. http://www.python.org/dev/peps/pep-0380/ The implementation in CPython isn't rounded up yet and lots of tests are missing from the test suite. But it's agreed that it'll make it into 3.3, and we should try to support it as well. It's a really nice feature. Stefan

2 3

Correct way of defining enums
by Stéfan van der Walt Nov. 30, 2011

Nov. 30, 2011

Hi all, What is currently the correct way of defining an enum? I am trying to call a NumPy function with an enum as its third argument, and the following does not compile: cimport numpy as np np.import_array() cdef enum NPY_SEARCHSIDE: NPY_SEARCHLEFT = 0 NPY_SEARCHRIGHT = 1 cdef sort_something(): cdef np.ndarray[double, ndim=1] sample_prob = np.empty(5, np.float64) cdef np.ndarray[double, ndim=1] cum_prob = np.empty(5, np.float64) cdef NPY_SEARCHSIDE side = NPY_SEARCHRIGHT results = np.PyArray_SearchSorted(cum_prob, sample_prob, side) It fails with: enum.c:1081:3: error: incompatible type for argument 3 of ‘(struct PyObject * (*)(struct PyArrayObject *, struct PyObject *, enum NPY_SEARCHSIDE))*(PyArray_API + 1048u)’ enum.c:1081:3: note: expected ‘NPY_SEARCHSIDE’ but argument is of type ‘struct PyObject *’ I tried different ways of defining the enum, e.g. cdef extern from "ndarraytypes.h": cpdef enum NPY_SEARCHSIDE: NPY_SEARCHLEFT = 0 NPY_SEARCHRIGHT = 1 But that doesn't work either. Any suggestions would be appreciated. Regards Stéfan

4 7

nested prange
by mark florisson Nov. 28, 2011

Nov. 28, 2011

I think we should allow nested prange()s, although it won't invoke nested OpenMP parallelism now, it still specifies that iterations are independent which can be useful for optimizations now (e.g. collapsing two loops into one) and in the future with other backends. Any thoughts or objections?

2 2

Type inference question
by Vitja Makarov Nov. 26, 2011

Nov. 26, 2011

Hi! I'm now trying to make inlined generator expressions work again. And I found strange thing: inlined_generator_expression.pyx: def range_sum(int N): """ >>> sum(range(10)) 45 >>> range_sum(10) 45 """ result = sum(i for i in range(N)) return result 'i' is expected to be integer, but it isn't So I tried simple example and 'i' is inferred as object: def bar(int N): cdef int result = 0 for i in range(N): result += i return result So, I'm wondering should it be inferred as int or not? -- vitja.

2 3

[BUG] cythonize() doesn't handle relative imports
by Devin Bayer Nov. 24, 2011

Nov. 24, 2011

Hi. I had a bunch of trouble with the setuptools extensions, so I wanted to try the new cythonize command, but it doesn't correctly handle dependencies. I have two files: src/_proto.pxd, which is empty src/_inrdb.pyx, which contains "from _proto cimport *" and cythonize(['src/_inrdb.pyx']) prints this "warning": > ('missing cimport', 'src/_inrdb.pyx') > libc.stdint > _proto > libc.string > /Library/Python/2.7/site-packages/Cython-0.15.1-py2.7-macosx-10.7-intel.egg/Cython/Includes/libc/stdint.pxd > /Library/Python/2.7/site-packages/Cython-0.15.1-py2.7-macosx-10.7-intel.egg/Cython/Includes/libc/string.pxd touching src/__init__.py and changing the cimport to src._proto resolves the issue. Thanks, Devin

1 0

memoryviews from C arrays
by mark florisson Nov. 23, 2011

Nov. 23, 2011

Hey, Currently when we want to convert C arrays to memoryview slices we have to do this: cdef int array[5][4] cdef int[:, :] slice = <int[:5, :4]> <int *> array I'd like to be able to write cdef int array[5][4] cdef int[:, :] slice slice = <int[:, :]> array # and slice = array I think that would be convenient, especially if we later on support variable sized C arrays. I also changed semantics with the cython.array callback, so now the data gets deallocated only if cython.array allocated it itself, otherwise a callback may be registered. Anyone opposed to the above semantics? Mark

2 2

Segmentation fault with generator expressions in a cdef class (Cython 0.15.1)
by Rauli Ruohonen Nov. 23, 2011

Nov. 23, 2011

Hi, I don't know if this has been reported yet (didn't notice a ticket with a quick look though), but I just downloaded and installed the latest Cython tarball and got a segfault this way: rauli@ubuntu:~/example$ ls bar.py foo.pyx rauli@ubuntu:~/example$ python bar.py Segmentation fault rauli@ubuntu:~/example$ cat bar.py import pyximport; pyximport.install() import foo foo.Foo() rauli@ubuntu:~/example$ cat foo.pyx cdef class Foo(object): cdef object bar def __init__(self): self.bar = 'baz' (i for i in self.bar) rauli@ubuntu:~/example$ uname -a Linux ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux rauli@ubuntu:~/example$ cython --version Cython version 0.15.1 rauli@ubuntu:~/example$ python --version Python 2.7.1+ rauli@ubuntu:~/example$

2 1

Undefined name 'entry' generate_type_import_call() 0.15.1 and trunk
by Matteo Bertozzi Nov. 21, 2011

Nov. 21, 2011

there's an undefined name 'entry' in ModuleNode.py generate_type_import_call() line 2171. I think that 'entry' should be replaced with 'type'. > diff --git a/Cython/Compiler/ModuleNode.py b/Cython/Compiler/ModuleNode.py > index 13cf6c8..ff9ca56 100644 > --- a/Cython/Compiler/ModuleNode.py > +++ b/Cython/Compiler/ModuleNode.py > @@ -2168,7 +2168,7 @@ class ModuleNode(Nodes.Node, Nodes.BlockNode): > else: > module_name = '__Pyx_BUILTIN_MODULE_NAME' > if type.name in Code.non_portable_builtins_map: > - condition, replacement = Code.non_portable_builtins_map[entry.name] > + condition, replacement = Code.non_portable_builtins_map[type.name] > code.putln("#if %s" % condition) > code.putln('%s = __Pyx_ImportType(%s, "%s", sizeof(%s), 1); %s' % ( > type.typeptr_cname,

2 1

Generators not closed on dealloc (Cython 0.15.1+, current git master)
by Matt Hagy Nov. 15, 2011

Nov. 15, 2011

Hi, Cython generators aren’t closed on dealloc and this can lead to cleanup code not being ran (see example below). I couldn’t find any reference to this issue on the trac or the wiki and therefore wanted to report it. If this is a know issue please disregard this post. I believe this can easily be corrected by adding the following line to the top of each generator dealloc function: if (p->resume_label != -1) __Pyx_Generator_Close(o); This explicitly closes the generator unless it’s already finished. For testing I manually added this code to the generated C file and it worked as expected. -Matt Example: I found this issue in the following code that relies upon a finally block to free memory. If not explicitly closed, the cleanup code is never executed and memory is leaked. ############################################ # generate_primes.pyx from libc.stdlib cimport malloc, realloc, free def generate_primes(unsigned int initial_buffer_size=64): cdef unsigned int test_number, i, N_primes, N_allocated cdef unsigned int *primes N_primes = 0 N_allocated = initial_buffer_size primes = <unsigned int*>malloc(N_allocated * sizeof(unsigned int)) if not primes: raise MemoryError test_number = 2 try: while 1: # is the current value of test_number prime? # i.e. is it not divisible by any of the already seen primes i = 0 while i<N_primes and test_number % primes[i] != 0: i += 1 if i == N_primes: yield test_number # grow primes array if needed if N_primes == N_allocated: N_allocated = N_allocated + 64 primes = <unsigned int*>realloc(primes, N_allocated * sizeof(unsigned int)) if not primes: raise MemoryError primes[N_primes] = test_number N_primes += 1 test_number += 1 finally: print 'clean up' free(primes) ###############################################

2 2

[RFE] cygdb not in entrypoints
by Devin Bayer Nov. 15, 2011

Nov. 15, 2011

Hi. Could you add cypdb to the entrypoints so that I can run it after an egg installation? Also, it would be great if you mentioned how to submit bugs in the README. It took me a while to find this list as the official bug submission channel. Thanks, Devin

2 1