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 o
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
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.
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
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 g
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
[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:
Sorry, this emphasizes the wrong thing. A try-statement emphasizes
that the body m
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
[Phillip]
> > In the second place, the most important cue to understanding the behavior
> > of a template block is the template function itself; the bare syntax gives
> > it the most prominence. Blocks like 'synchronized(self):' should be
> > instantly comprehensible to Java programmers, for examp
Guido van Rossum wrote:
>> Another possibility just occurred to me. How about "using"?
>
> Blah. I'm beginning to like block just fine. With using, the choice of
> word for the generator name becomes iffy IMO; and it almost sounds
> like it's a simple renaming: "using X as Y" could mean "Y = X".
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
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):
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, bu
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
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:
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 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 co
Guido van Rossum wrote:
[Ron Adam]
How about 'serve' as in a server of items from a service?
No, please. This has way too strong connotations with network protocols.
Errr... you're right of course... :-/ (I was thinking *way* to narrow.)
I think the context is correct, just need a synonym that
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
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 f
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 th
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 body
[Ron Adam]
> How about 'serve' as in a server of items from a service?
No, please. This has way too strong connotations with network protocols.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@pyth
[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 ...
[Jim Jewett]
> I would have been very happy with that a week ago. Seeing the
> specific implementation
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
[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 an
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 too, but it was shot down at
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
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
> 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 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
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 Hud
[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 beaut
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> # Non-finalised semantics
> arg = None
> while True:
> try:
> VAR1 = next(itr, arg)
> except StopIteration:
> BLOCK2
> break
> arg = None
>
At 09:38 AM 4/29/05 -0700, Aahz wrote:
-1 -- the Zen of Python implies that we should be able to tell which
construct we're using at the beginning of the line.
Hm, maybe we should just use "@", then. :)
e.g.
@synchronized(self):
@with_file("foo") as f:
# etc.
Although I'd p
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(
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
>
>
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 NAM
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 fr
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 released
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 t
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 tha
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:
http://mail.python.org/mailman/options/python-dev/arch
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
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 = urllib.urlopen("htt
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 complet
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,
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
http://mail.python.org/mailman/li
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
>
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 lim
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
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
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
Guido van Rossum wrote:
How about, instead of trying to emphasize how different a
block-statement is from a for-loop, we emphasize their similarity?
If you want to emphasise the similarity, the following syntax and explanation is
something that occurred to me during lunch today:
Python offers two
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 a
> [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 th
Greg Ewing <[EMAIL PROTECTED]> wrote:
> That actually looks pretty reasonable.
>
> Hmmm. "Patterns of structure." Maybe we could call it a
> "struct" statement.
>
> struct opening(foo) as f:
>...
>
> Then we could confuse both C *and* Ruby programmers at
> the same time! :-)
And Py
57 matches
Mail list logo