Robert Bradshaw wrote:
> On May 13, 2008, at 5:15 AM, Stefan Behnel wrote:
>>     for x in iterable:
>>
>> and
>>
>>     for x in 1 < x <= 5:
>>
>> instead of the new
>>
>>     for 1 < x <= 5:
>>
>> purely for readability (and obviously keeping the old "from"
>> spelling for
>> compatibility).
>
> I'm -1 for having lots of multiple ways to do for loops

I agree, but since Greg brought up the third way of doing it because he
didn't like the integer loop syntax, I wanted to discuss what a good
syntax would be here *iff* he wants to change it.


> Also, "from" makes it
> clear that this is a special cython loop--consider the following:
>
> x = 1
>
> class A:
>      def __gt__(self, other):
>          return range(3,7)
>
> for x in 0 <= x < A():
>      print x
>
>
> This is valid Python (prints 3, 4, 5, 6), and would act completely
> differently under your proposal.

What an ugly example. ;)

But I see that this syntax cannot be accepted in that case. Which leaves
us with the question if Cython should support the shorted integer loop
syntax which Pyrex now has. I guess supporting it and not promoting it
would be ok.


> I do think optimizing enumerate/zip/etc is feasible and probably
> worthwhile.

I'm just concerned about too many special cases in the optimiser.

If we start optimising these (and I would prefer giving range(), zip() &
friends their Py3 iterator semantics in this case), we should come up with
a generic way to support iterator chaining in C code rather than making
the looping code even more complicated and special casing.

When we loop over a chain of iterators, this example

    for i,k in enumerate(range(100)):
        l += i*k

could become something like this:

    c_range_state = c_range_new(100)
    c_enumerate_state = c_enumerate_new()

    while 1:
        temp1 = c_range_next(c_range_state); if (!temp1) ...
        temp2 = c_enumerate_next(c_enumerate_state, temp1); if (!temp2) ...
        i,k = temp2
        l += i*k
    c_range_free(c_range_state)
    c_enumerate_free(c_enumerate_state)

Maybe a subclassable ForLoopNode class with a way to generate the start,
body and end code of a loop might be an idea. That way, we could chain the
subclasses that know how to loop over a list, range(), enumerate(), etc.,
and we wouldn't even need malloc as everything could live in local
variables.

Stefan

_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to