On May 24, 2010, at 11:13 AM, Stefan Behnel wrote: > Robert Bradshaw, 24.05.2010 18:03: >> On May 24, 2010, at 4:50 AM, Stefan Behnel wrote: >>> Second question: should this be enabled for list/set/dict >>> comprehensions in >>> Cython 0.13 as well? I think we already agreed that the leaking loop >>> variables should be considered a bug that rarely has an impact on >>> existing >>> code. In Py2, only list comprehensions leak their variable, whereas >>> genexps >>> have their own scope. In Py3, all comprehensions and genexps have >>> their own >>> scope. I would prefer unifying the scoping rules in Cython 0.13 as >>> well. >>> (It's already implemented in cython-closures, although disabling it >>> would be trivial). >> >> I think we should strive for Py2 compatibility, even in corner cases. >> With the -3 flag, we should behave as Python 3 (i.e. not leaking >> variables as you suggest). > > I know. However, Py2 doesn't have set/dict comprehensions (yet), and > both > are defined in Py3 as not leaking variables. So we already violate > existing > Python behaviour anyway. Although it's certainly not hard to argue > that, if > all three kinds of comprehensions existed in Py2, they'd behave all > the > same way.
That's a good point, it would probably make more sense for them to all be consistent. > My main concern isn't even breaking code by ripping out the loop > variable(s), which most code won't rely upon anyway. It's the fact > that the > behaviour will change with the -3 switch because type declarations > will > disappear from the genexpr scope. That will break code in a much more > subtle way, and may lead to hard to find/understand changes in > behaviour. > We can warn about it, but I always find it better to prevent non- > future > proof code from getting written as early as possible. Leaking vs. non-leaking loop variables, though I'd hope it isn't counted on much, can be a subtle difference too. I think the most important barrier to lower is the pure vs. compiled one for straight Python. > Can we at least emit a warning that there is a better way to do it, > when we > find that a comprehension is based on a cdef-ed variable? Yes, we should probably omit a warning. Another idea to throw out there is that we could borrow the type from the containing scope, if any, just not alter its value. Thinking of it, I've actually used this a lot: cdef int i L = [foo[i] for i in range(...)] or other more complicated expressions. -1 to changing it and making all such loops slow Python loops. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
