On 4/29/05, Reinhold Birkenfeld wrote:
> Date: Sat, 30 Apr 2005 00:53:12 +0200
> From: Reinhold Birkenfeld <[EMAIL PROTECTED]>
> Subject: [Python-Dev] Re: PEP 340 - possible new name for
>block-statement
> To: python-dev@python.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/pla
[Phillip]
> By the way, I notice PEP 340 has two outstanding items with my name on
> them; let me see if I can help eliminate one real quick.
>
> Tracebacks: it occurs to me that I may have unintentionally given the
> impression that I need to pass in an arbitrary traceback, when in fact I
> only
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
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 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
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):
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:
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
[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
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
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
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
[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
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
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
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
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
> Far too close to the "for" loop, IMHO. I read that, I'd have to remind
> myself every time, "now, which one is it that can receive values passed
> back in: for ... in, or in ... for?"
Whoa! Read the PEP closely. Passing a value back to the iterator
(using "continue EXPR") is supported both in th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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?
|
| A regular old loop over a sequence or iterable is written as:
|
| for VAR in EXPR:
|
Neil Schemenauer wrote:
A variation on this with somewhat different semantics swaps the keywords:
in EXPR for VAR:
BLOCK
Looks weird to my eyes.
Probably makes perfect sense if you're Dutch, though. :-)
--
Greg Ewing, Computer Science Dept, +--+
Univers
On Thu, Apr 28, 2005 at 03:55:03PM -0700, Guido van Rossum wrote:
> A variation on this with somewhat different semantics swaps the keywords:
>
> in EXPR for VAR:
> BLOCK
Looks weird to my eyes.
On a related note, I was thinking about the extra cleanup 'block'
provides. If the 'file
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 variation on this with somewhat different semantics swaps the keywords:
34 matches
Mail list logo
