On 5/5/05, Steven Bethard [EMAIL PROTECTED] wrote:
On 5/5/05, Paul Moore [EMAIL PROTECTED] wrote:
And does your proposal allow for continue EXPR as supported by PEP
340? I can't see that it could, given that your proposal treats block
statements as not being loops.
Read PEP 340 again --
On 5/6/05, Greg Ewing [EMAIL PROTECTED] wrote:
Seems to me it should be up to the block iterator whether
a break statement gets caught or propagated, since it's
up to the block iterator whether the construct behaves
like a loop or not.
This could be achieved by having a separate exception
Guido van Rossum wrote:
Maybe generators are not the way to go, but could be
supported natively by providing a __block__ function, very similarly to
sequences providing an __iter__ function for for-loops?
Sorry, I have no idea what you are proposing here.
I was suggesting that the feature
On Thu, 5 May 2005, Delaney, Timothy C (Timothy) wrote:
Aahz wrote:
My standard workaround is using exceptions, but I'm not sure how that
interacts with a block:
try:
for name in filenames:
with opened(name) as f:
if f.read(2) == 0xFEB0:
Steven Bethard wrote:
Makes me wonder if we shouldn't just return to the __enter__() and
__exit__() names of PEP 310[1] where for a generator __enter__() is
just an alias for next(). We could even require Phillip J. Eby's
blockgenerator decorator to rename next() to __enter__(), and add
the
Alex Martelli wrote:
Looking for a file with a certain magicnumber in its 1st two bytes...?
for name in filenames:
opening(name) as f:
if f.read(2) == 0xFEB0: break
This does seem to make real-life sense to me...
Also consider the vast semantic differences between:
Ronald Oussoren wrote:
What's bothering me about the proposed semantics is that block
statement behaves like a loop while most use cases do no looping
whatsoever.
Furthermore the it doesn't feel like loop either. In all three
examples on this page I'd assume
that the break would break out
On 5/5/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
Makes me wonder if we shouldn't just return to the __enter__() and
__exit__() names of PEP 310[1] where for a generator __enter__() is
just an alias for next(). We could even require Phillip J. Eby's
blockgenerator
Ka-Ping Yee [EMAIL PROTECTED] wrote:
On Thu, 5 May 2005, Josiah Carlson wrote:
Ka-Ping Yee [EMAIL PROTECTED] wrote:
continue with 2
There is something about action which level that I just don't like.
Just to clarify: if by level you mean nesting level, did it appear
that the 2
On 5/5/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Well, Michael Hudson and Paul Moore are the current authors of PEP 310, so
updating it with any of my ideas would be their call.
I'm willing to consider an update - I don't know Michael's view. I
currently find myself in the odd situation of
On 5/5/05, Paul Moore [EMAIL PROTECTED] wrote:
And does your proposal allow for continue EXPR as supported by PEP
340? I can't see that it could, given that your proposal treats block
statements as not being loops.
Read PEP 340 again -- the continue EXPR syntax is orthogonal to the
discussion
Seems to me it should be up to the block iterator whether
a break statement gets caught or propagated, since it's
up to the block iterator whether the construct behaves
like a loop or not.
This could be achieved by having a separate exception
for breaks, as originally proposed.
If the iterator
Simon Percivall wrote:
And this is not confusing in what way?
I don't think it's any less confusing than having a
construct in the first place which can either be a
loop or not. You need to know the semantics of the
block iterator in order to know whether it's a loop.
Once you know that, you
Delaney, Timothy C (Timothy) wrote:
In this scenario (and I'm not saying I approve or disapprove) I think
BreakIteration should inherit from StopIteration (thus retaining the
existing PEP 340 semantics if uncaught)::
Not sure I understand. The point of my suggestion was
to *not* retain
Paul Moore wrote:
Oh, and by the way - I prefer the keywordless form of the block
statement (as used in my examples above). But it may exacerbate the
issue with break unless we have a really strong name for these
constructs
may exacerbate? Something of an understatement, unfortunately.
On May 4, 2005, at 01:57, Paul Moore wrote:
tried to construct a plausible example, I couldn't find a case which
made real-life sense. For example, with Nicolas' original example:
for name in filenames:
opening(name) as f:
if condition: break
I can't think of a
On 5/4/05, Alex Martelli [EMAIL PROTECTED] wrote:
On May 4, 2005, at 01:57, Paul Moore wrote:
I can't think of a reasonable condition which wouldn't involve reading
the file - which either involves an inner loop (and we already can't
break out of two loops, so the third one implied by
On 5/4/05, Nick Coghlan [EMAIL PROTECTED] wrote:
With single-pass semantics, an iterator used in a block statement would have
it's .next() method called exactly once, and it's __exit__ method called
exactly
once if the call to .next() does not raise StopIteration. And there's no need
to
Paul Moore wrote:
On 5/4/05, Alex Martelli [EMAIL PROTECTED] wrote:
On May 4, 2005, at 01:57, Paul Moore wrote:
I can't think of a reasonable condition which wouldn't involve reading
the file - which either involves an inner loop (and we already can't
break out of two loops, so the
Alex Martelli wrote:
Looking for a file with a certain magicnumber in its 1st two bytes...?
for name in filenames:
opening(name) as f:
if f.read(2) == 0xFEB0: break
This does seem to make real-life sense to me...
I'd like to suggest a small language enhancement that would
On Wed, 4 May 2005, Shane Hathaway wrote:
I'd like to suggest a small language enhancement that would fix this
example. Allow the break and continue statements to use a keyword,
either for or while, to state that the code should break out of both
the block statement and the innermost for or
Ka-Ping Yee wrote:
On Wed, 4 May 2005, Shane Hathaway wrote:
for name in filenames:
opening(name) as f:
if f.read(2) == 0xFEB0:
break for
This is very elegant.
Thanks.
It works beautifully with break, though at
first that natural analogs continue
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
break
time.sleep(1)
Will never break out of the enclosing while loop. This is because the
break breaks the while loop that the
Tom Rothamel a écrit :
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
break
time.sleep(1)
Will never break out of the enclosing while loop. This is because the
Pierre == Pierre Barbier de Reuille [EMAIL PROTECTED] writes:
Pierre Tom Rothamel a écrit :
I have a question/suggestion about PEP 340.
As I read the PEP right now, the code:
while True:
block synchronized(v1):
if v1.field:
Skip Montanaro a écrit :
[...]
Yeah, but block synchronized(v1) doesn't look like a loop. I think this
might be a common stumbling block for people using this construct.
Skip
Well, this can be a problem, because indeed the black-statement
introduce a new loop construct in Python.
[Skip Montanaro]
Yeah, but block synchronized(v1) doesn't look like a loop. I think this
might be a common stumbling block for people using this construct.
How many try/finally statements have you written inside a loop? In my
experience this is extrmely rare. I found no occurrences in the
[Skip Montanaro]
Yeah, but block synchronized(v1) doesn't look like a loop. I think
this might be a common stumbling block for people using this
construct.
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is
Guido van Rossum wrote:
[Skip Montanaro]
Guido How many try/finally statements have you written inside a loop?
Guido In my experience this is extrmely rare. I found no
Guido occurrences in the standard library.
How'd we start talking about try/finally?
Because it provides by
29 matches
Mail list logo
