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]
>>
>> f() certainly shouldn't raise a StopIteration. There's no reason for
>> doing
>> th
On Thu, Jul 10, 2008 at 2:26 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> When exercising 2-to-3 on Zodb at the EuroPython sprints, we also found
> another oddity. This code works in 2.6 but fails in 3.0 (it looks for the
> free variable in the global scope instead of the enclosing local sco
From: "Guido van Rossum" <[EMAIL PROTECTED]>
To be sure, IMO the generator expression is wrong in interpreting the
StopIteration exception! It should fail the same way the list
comprehension fails.
When exercising 2-to-3 on Zodb at the EuroPython sprints, we also found another oddity. This cod
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]
f() certainly shouldn't raise a StopIteration. There's no reason for doing
that, other than taking dirty implementation shortcut
Antoine Pitrou wrote:
> Carl Johnson carlsensei.com> writes:
>> This raises the question, do we need both a ``break`` statement and
>> ``raise StopIteration``?
>> Can the former just be made into syntatic sugar
>> for the later? Or is this the hobgoblin of a little mind?
Yes, no, and ??.
One
On Thu, Jul 10, 2008 at 6:28 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Carl Johnson carlsensei.com> writes:
>>
>> However, it can be argued that in Python 3 list comprehensions should be
>> thought of as "syntatic sugar" for ``list(generator expression)`` not a
>> for-loop with an accumulato
Carl Johnson carlsensei.com> writes:
>
> However, it can be argued that in Python 3 list comprehensions should be
> thought of as "syntatic sugar" for ``list(generator expression)`` not a
> for-loop with an accumulator. (This seems to be the motivation for no
> longer "leaking" variables from lis
The primary use of Py_FindMethod was to implement a tp_getattr slot
handler. Now that it has been removed, there is nothing remaining in
the py3k codebase that actually uses the tp_getattr slot!
It has been 12 years since tp_getattro was introduced. Is it time to
finally phase out tp_getattr?
Ore
Filed http://bugs.python.org/issue3331
I added this to the bottom of the report, but perhaps it should be a
discussion topic, not a "bug" per se:
One might object that the behavior of the list comprehension is
identical to that of a for-loop:
>>> r = []
>>> for x in range(100):
