closures

[john_perry_usm]

Hi

Are closures permanently broken in sage-4.8's cython, or was it a
passing fashion? When I use something like this in a pyx file:

cpdef test():
a = [1,2,3,4]
if any(b < 0 for b in a): print "yes"
else: print "no"
return


I get this error:


_Users_user_common_Research_SAGE_programs_gb_detection_dynamic_algorithm_coin_copy_bug_pyx_0.pyx:
90:8: closures inside cdef functions not yet supported

alpha0 doesn't give me this problem. I haven't tried others.

regards
john perry

[Volker Braun]

We did upgrade to cython-0.15.1 early on in the 4.8.alpha series, fwiw. I guess line 90 is the any() construct. Perhaps that was already broken with the old cython, it just didn't know? E.g. what happened if the generator raised an exception?

[john_perry_usm]

Thanks for the reply.

On Jan 7, 11:09 am, Volker Braun <vbraun.n...@gmail.com> wrote:
> We did upgrade to cython-0.15.1 early on in the 4.8.alpha series, fwiw. I
> guess line 90 is the any() construct.

Yeah, I mixed source code for a test program with an error message
from an actual program, sorry.

> Perhaps that was already broken with
> the old cython, it just didn't know? E.g. what happened if the generator
> raised an exception?

The code works perfectly fine on sage-4.6.2 sage-4.7.2alpha2, and
4.8.alpha0. I didn't have it running only this test code; I had a much
more complicated program working fine. The Cython compiler refuses it
in 4.8alpha4.

john perry

[Volker Braun]

I think generators are only supported in def functions, not c(p)def. Apparently it was a bug that there was no error produced in older cython versions:

https://github.com/cython/cython/commit/0ea50f346d7cf6aecea4ddab65af85c936f6693b

As to why it worked for you, perhaps you only called the Python version of your cpdef function. Or you just didn't notice some bad side effect (like memory leaking).

[john_perry_usm]

> As to why it worked for you, perhaps you only called the Python version of
> your cpdef function.

I'm pretty sure I did not call the Python version in the production
code, but maybe. I did call a cpdef function from Python, which then
called another cpdef, which called another cpdef. At some level on the
stack, we reach this particular function, but by then we should be in
the C side, yes?

> Or you just didn't notice some bad side effect (like memory leaking).

That could be.

john perry