[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
[Guido]
Maybe. You're not the first one
Guido van Rossum [EMAIL PROTECTED] wrote:
[Nicolas Fleury]
I would prefer something that would be
understandable for a newbie's eyes, even if it fits more with common
usage than with the real semantics behind it. For example a Boost-like
keyword like:
scoped EXPR as VAR:
Guido van Rossum [EMAIL PROTECTED] writes:
[Greg Ewing]
Elegant as the idea behind PEP 340 is, I can't shake
the feeling that it's an abuse of generators. It seems
to go to a lot of trouble and complication so you
can write a generator and pretend it's a function
taking a block argument.
Brian Sabbey [EMAIL PROTECTED] writes:
It is possible to implement thunks without them creating their own
frame. They can reuse the frame of the surrounding function. So a new
frame does not need to be created when the thunk is called, and, much
like with a yield statement, the frame is not
Nick Coghlan a écrit :
Python offers two variants on the basic iterative loop.
for NAME from EXPR: enforces finalisation of the iterator. At loop
completion, a well-behaved iterator is always completely exhausted. This
form supports block management operations, that ensure timely release of
On 4/29/05, Shane Hathaway [EMAIL PROTECTED] wrote:
I think this concept can be explained clearly. I'd like to try
explaining PEP 340 to someone new to Python but not new to programming.
I'll use the term block iterator to refer to the new type of
iterator. This is according to my limited
On 4/29/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Message: 2
Date: Thu, 28 Apr 2005 21:56:42 -0600
From: Shane Hathaway [EMAIL PROTECTED]
Subject: Re: [Python-Dev] Re: anonymous blocks
To: [EMAIL PROTECTED]
Cc: Ka-Ping Yee [EMAIL PROTECTED], Python Developers List
Hello,
Shane Hathaway wrote:
Is it understandable so far?
Definitely yes! I had the structure upside-down; your explanation is
right on target.
Thanks!
--
Luis Bruno
___
Python-Dev mailing list
Python-Dev@python.org
Luis P Caamano wrote:
I've been skipping most of the anonymous block discussion and thus,
I only had a very vague idea of what it was about until I read this
explanation.
Yes, it is understandable -- assuming it's correct :-)
To my surprise, the explanation is now in the PEP. (Thanks,
Nick Coghlan:
Python offers two variants on the basic iterative loop.
for NAME in EXPR: skips the finalisation step. At loop
completion, a well-behaved iterator may still contain additional values.
for NAME from EXPR: enforces finalisation of the iterator.
... At loop completion, a
How about bracket or bracket_with? As in:
bracket_with synchronized(lock):
BLOCK
bracket_with opening(/etc/passwd) as f:
for line in f:
print line.rstrip()
bracket_with transactional(db):
db.store()
bracket_with auto_retry(3, IOError):
f =
PEP 340 describes the block statement translation as:
itr = EXPR1
val = arg = None
ret = False
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
if ret:
return val
me It uses a variable ret that is always False.
Gaack. Please ignore.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Pierre Barbier de Reuille wrote:
One main reason is a common error could be (using the synchronised
iterator introduced in the PEP):
for l in synchronised(mylock):
do_something()
It will compile, run, never raise any error but the lock will be
acquired and never released !
It's better than
Jim Jewett wrote:
Why not just agressively run the finalization on both forms when the
reference count permits?
So the iterator is always finalised if the for loop has the only reference?
Two problems I can see there is that naming the target of the for loop would
prevent it being finalised, and
Nick Coghlan a écrit :
Pierre Barbier de Reuille wrote:
One main reason is a common error could be (using the synchronised
iterator introduced in the PEP):
for l in synchronised(mylock):
do_something()
It will compile, run, never raise any error but the lock will be
acquired and never
On Thu, Apr 28, 2005, Brian Sabbey wrote:
It is possible to implement thunks without them creating their own frame.
They can reuse the frame of the surrounding function. So a new frame does
not need to be created when the thunk is called, and, much like with a
yield statement, the frame
On Fri, Apr 29, 2005, Nick Coghlan wrote:
If you want to emphasise the similarity, the following syntax and
explanation is something that occurred to me during lunch today:
We don't want to emphasize the similarity.
Python offers two variants on the basic iterative loop.
for NAME from
On 4/28/05, Guido van Rossum [EMAIL PROTECTED] wrote:
How about, instead of trying to emphasize how different a
block-statement is from a for-loop, we emphasize their similarity?
A regular old loop over a sequence or iterable is written as:
for VAR in EXPR:
BLOCK
A
Nick Coghlan [EMAIL PROTECTED] wrote:
Then, in Py3K, finalisation could simply become the default for loop
behaviour.
However, the '__finalise__' flag would result in some impressive code bloat,
as
any for loop would need to expand to:
itr = iter(EXPR1)
if getattr(itr,
Nick Coghlan [EMAIL PROTECTED] wrote:
# Non-finalised semantics
arg = None
while True:
try:
VAR1 = next(itr, arg)
except StopIteration:
BLOCK2
break
arg = None
Brian Sabbey:
It is possible to implement thunks without them creating their own
frame. They can reuse the frame of the surrounding function ...
The implementation just needs to take care
to save and restore members of the frame that get clobbered when the
thunk is running.
Michael Hudson:
On 4/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as f:
# etc.
I'd like that too, but it was shot down at least once. Maybe we can
resurrect it?
I agree, but does this then work:
x = opening(foo)
...stuff...
x as f:
# etc
? And if not, why not? And if yes, what happens if stuff raises an
exception?
Forget it -- the above is probably addressed by the PEP and doesn't
really depend on whether there's a kw or not.
On Fri, Apr 29, 2005, Guido van Rossum wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as f:
# etc.
I'd like that too, but it was shot down at least once. Maybe we can
resurrect it?
Guido van Rossum:
One [of many separate ideas in PEP 340] is turning generators
into more general coroutines: continue EXPR passes the expression
to the iterator's next() method ...
I would have been very happy with that a week ago. Seeing the
specific implementation changed my mind.
The
[Michael Hudson]
I think the making-generators-more-sexy thing is nice, but I'm think
that's almost orthogonal.
Not entirely. I agree that continue EXPR calling next(EXPR) which
enables yield-expressions is entirely orthogonal.
But there are already two PEPs asking for passing exceptions
Jim Jewett wrote:
Nick Coghlan:
Python offers two variants on the basic iterative loop.
for NAME in EXPR: skips the finalisation step. At loop
completion, a well-behaved iterator may still contain additional values.
for NAME from EXPR: enforces finalisation of the iterator.
... At loop
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti)
and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding
function can share the same code. The thunk gets compiled into the
function the same way the
I don't know whether it's true for all the PEP 340 use cases, but the all the
current examples would read very naturally if the block-template could be
specified in an extended try statement:
1. A template for ensuring that a lock, acquired at the start of a
block, is released when
Guido van Rossum:
-- but it's more efficient, since calling yield doesn't create a frame.
Neither should a thunk.
The other problem with thunks is that once we think of them as the
anonymous functions they are, we're pretty much forced to say that a
return statement in a thunk returns from
On Thu, 28 Apr 2005, Shane Hathaway wrote:
[...]
I think this concept can be explained clearly. I'd like to try
explaining PEP 340 to someone new to Python but not new to programming.
[...snip explanation...]
Is it understandable so far?
Yes, excellent. Speaking as somebody who scanned the
On 4/29/05, Brian Sabbey [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
The only members that need special attention are (f_code, f_lasti)
and possibly (f_blockstack, f_iblock).
You don't even need to take care of f_code. The thunk and its surrounding
function can share the same code. The
Michael Spencer:
I don't know whether it's true for all the PEP 340 use cases, but the all the
current examples would read very naturally if the block-template could be
specified in an extended try statement:
1. A template for ensuring that a lock, acquired at the start of a
On Fri, Apr 29, 2005, Phillip J. Eby wrote:
At 10:42 AM 4/29/05 -0700, Aahz wrote:
On Fri, Apr 29, 2005, Guido van Rossum wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as f:
# etc.
I'd like that
Robin Munn wrote:
[snip]
Another possibility just occurred to me. How about using?
~using EXPR as VAR:
~BLOCK
Examples from PEP 340:
==
def synchronized(lock):
...
using synchronized(myLock):
...
= (+0)
def opening(filename, mode=r):
...
using opening(/etc/passwd) as f:
...
Guido van Rossum wrote:
[Nicolas Fleury]
scoped EXPR as VAR:
BLOCK
Definitely not. In too many languages, a scope is a new namespace,
and that's exactly what a block (by whichever name) is *not*.
Humm... what about context?
context EXPR as VAR:
BLOCK
I may answer the question myself, but
At 12:05 PM 4/29/05 -0700, Aahz wrote:
On Fri, Apr 29, 2005, Phillip J. Eby wrote:
At 10:42 AM 4/29/05 -0700, Aahz wrote:
On Fri, Apr 29, 2005, Guido van Rossum wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as
On Fri, Apr 29, 2005, Phillip J. Eby wrote:
Actually, I've just realized that I was misled by your argument into
thinking that the possibility of confusing a multi-line call and a block of
this sort is a problem. It's not, because template blocks can be viewed as
multi-line calls that
On 4/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as f:
# etc.
I'd like that too, but it was shot down at least once. Maybe we can
resurrect it?
On 29 apr 2005, at 20.10, Brian Sabbey wrote:
[...] The thunk and its surrounding function can share the same
code. The thunk gets compiled into the function the same way the
body of a for loop would.
This seems really, truly, nasty! Wouldn't this require you to check
the source code of the
Pierre Barbier de Reuille wrote:
Mmmmh ... why introduce a new flag ? Can't you just test the presence of
the __error__ method ? This would lift your problem wouldn't it ?
Perhaps - it would require doing something a little tricky with generators to
allow the programmer to specify whether the
Guido van Rossum wrote:
[Phillip J. Eby]
Although I'd personally prefer a no-keyword approach:
synchronized(self):
with_file(foo) as f:
# etc.
I'd like that too, but it was shot down at least once. Maybe we can
resurrect it?
opening(foo) as f:
# etc.
is just a
On Fri, 29 Apr 2005, Guido van Rossum wrote:
The more I think about it the more I like having no keyword at all
(see other messages).
I hope you'll reconsider this. I really think introducing a new
statement requires a keyword, for pedagogical reasons as well as
readability and consistency.
At 04:02 PM 4/29/05 -0700, Guido van Rossum wrote:
Actually, I think this is a nice way to have my cake and eat it too:
on the one hand, there still isn't any user-defined syntax, because
the keyword-less block syntax is still fixed by the compiler. On the
other hand, people are free to *think* of
At 08:21 PM 4/29/05 -0500, Ka-Ping Yee wrote:
All the statements in Python are associated with keywords, except
for assignment, which is simple and extremely common. I don't
think the block statement is simple enough or common enough for
that; its semantics are much too significant to be flagged
46 matches
Mail list logo
