From: "Guido van Rossum" <[EMAIL PROTECTED]>
The new failure in 3.0 is a side effect of the translation (mostly) of
list comps into genexps. The underlying problem is that the genexp
creates a function scope, and function scopes don't have access to the
surrounding class body scope. (There's a re
Raymond Hettinger wrote:
Would you be open to an alternate implementation for list/set/dict comps
that doesn't use a genexps? That would solve the scope problem, the
performance hit, and make tracing more straight-forward.
If you're open to it, I can see if the EuroPython sprinters can find a
From: "Nick Coghlan" <[EMAIL PROTECTED]>
Georg and I tried doing it that way and had major problems trying to get it to work - the hard part is that the body of the list
comp (which may include nested list comps, lambda functions and generator expressions) needs to be able to see the iteration
v
Raymond Hettinger wrote:
From: "Nick Coghlan" <[EMAIL PROTECTED]>
Georg and I tried doing it that way and had major problems trying to
get it to work - the hard part is that the body of the list comp
(which may include nested list comps, lambda functions and generator
expressions) needs to be
On Fri, Jul 11, 2008 at 12:00 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Guido van Rossum" <[EMAIL PROTECTED]>
>>
>> The new failure in 3.0 is a side effect of the translation (mostly) of
>> list comps into genexps. The underlying problem is that the genexp
>> creates a function scop
On Thu, Jul 10, 2008 at 11:45 PM, Stefan Behnel <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
>> Antoine Pitrou wrote:
>>
>>> That is, in your example:
>>>
>>> >>> def f(x):
>>> ... if x > 5: raise StopIteration
>>> ...
>>> >>> list(x for x in range(100) if not f(x))
>>> [0, 1, 2, 3, 4, 5]
>>>
Stefan Behnel wrote:
While I agree with this being bad design, I do think that the above is a bug.
It's a different thing if the iterable in the list comp/genexp raises a
StopIteration, or if the conditional does it. And not silently catching
anything raised by the latter sounds like the right t
Raymond Hettinger wrote:
From: "Nick Coghlan" <[EMAIL PROTECTED]>
Georg and I tried doing it that way and had major problems trying to
get it to work - the hard part is that the body of the list comp
(which may include nested list comps, lambda functions and generator
expressions) needs to be
Carl Johnson wrote:
Certainly, it's an inconsistency compared to generator expressions, but
is it a bug? I know that Python 3000 is making it so that list
comprehension variables don't leak anymore, so I take it that the goal
is to have them be more similar to generator expressions than not. Th
On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Stefan Behnel wrote:
>
>> While I agree with this being bad design, I do think that the above is a
>> bug.
>> It's a different thing if the iterable in the list comp/genexp raises a
>> StopIteration, or if the conditional does
Adam Olsen wrote:
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.
Would you do that only for genexps, or for generators
in general?
The current behaviour seems to be that if you explicitly
raise S
On Fri, Jul 11, 2008 at 7:10 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Adam Olsen wrote:
>>
>> However, since the genexp considers all improper ones to be in error,
>> it could wrap them with a RuntimeError and pass it through .next()
>> instead.
>
> Would you do that only for genexps, or for gen
Adam Olsen wrote:
> On Fri, Jul 11, 2008 at 6:11 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Stefan Behnel wrote:
>>
>>> While I agree with this being bad design, I do think that the above is a
>>> bug.
>>> It's a different thing if the iterable in the list comp/genexp raises a
>>> StopIteration,
Nick Coghlan wrote:
Carl Johnson wrote:
Certainly, it's an inconsistency compared to generator expressions,
but is it a bug? I know that Python 3000 is making it so that list
comprehension variables don't leak anymore, so I take it that the goal
is to have them be more similar to generator e
Greg Ewing wrote:
Adam Olsen wrote:
However, since the genexp considers all improper ones to be in error,
it could wrap them with a RuntimeError and pass it through .next()
instead.
Would you do that only for genexps, or for generators
in general?
For me, the former. For generators in gen
Raymond Hettinger wrote:
> I know this group doesn't care about Psyco, but it was
> nice that psyco could handle listcomps just like it could with
> regular for-loops. Turning it into a genexp stops psyco in its tracks.
> Likewise, Cython won't be able to handle the semantics.
Regarding Cython, I
16 matches
Mail list logo
