Guido van Rossum [EMAIL PROTECTED] writes:
[Michael Hudson, after much thinking aloud]
Yeah, sorry about that :)
Oh, I guess the point is that with a decorated generator you can yield
a value to be used as VAR, rather than just discarding the value as
here. Hmm.
Right. (I thought it was
I just read Raymond Chen's rant against control flow macros:
http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
I think this pretty much kills PEP 340, as well as Nick Coghlan's
alternative: both proposals let you write a template that can be
used to hide exception-catching code,
Guido van Rossum [EMAIL PROTECTED] writes:
I just read Raymond Chen's rant against control flow macros:
http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
I think this pretty much kills PEP 340, as well as Nick Coghlan's
alternative: both proposals let you write a template that
At 03:05 AM 5/13/2005 -0700, Guido van Rossum wrote:
So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a template for
the do-statement enough to accept the slightly increased complexity?
Since the do protocol is now distinct
[Michael Hudson, after much thinking aloud]
Oh, I guess the point is that with a decorated generator you can yield
a value to be used as VAR, rather than just discarding the value as
here. Hmm.
Right. (I thought it was worth quoting this for the benefit of other
who went down the same trail
At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote:
The 'oke' argument is so that the author of transactional() can decide
what to do with a non-local goto: commit, rollback or hit the author
over the head with a big stick.
Since this is just a replacement for a try/except/finally block, I'd
On 5/13/05, Guido van Rossum [EMAIL PROTECTED] wrote:
So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a template for
the do-statement enough to accept the slightly increased complexity?
+0. I'm not thoroughly convinced
[Guido]
The 'oke' argument is so that the author of transactional() can decide
what to do with a non-local goto: commit, rollback or hit the author
over the head with a big stick.
[Phillip J. Eby]
Since this is just a replacement for a try/except/finally block, I'd expect
that in a
[Steven Bethard]
+0. I'm not thoroughly convinced that generators are that much easier
to read than a class. But I don't find them hard to read, and I think
it would only take a little effort to learn that generators might not
always be intended to build iterators.
I am proposing (like
Guido van Rossum wrote:
I just read Raymond Chen's rant against control flow macros:
http://blogs.msdn.com/oldnewthing/archive/2005/01/06/347666.aspx
I think this pretty much kills PEP 340, as well as Nick Coghlan's
alternative: both proposals let you write a template that can be
used to
Michael Hudson wrote:
Looking at my above code, no (even though I think I've rendered the
point moot...). Compare and contrast:
@template
def redirected_stdout(out):
save_stdout = sys.stdout
sys.stdout = out
yield None
sys.stdout = save_stdout
class
[Nick Coghlan]
The ban on yielding inside try/finally will need to be extended to yielding
inside user defined statements until such time as an iterator finalisation
protocol is chosen, though.
Ah! Good point. This breaks PEP 340 example 5. No big deal, but worth noting.
--
--Guido van
Guido van Rossum wrote:
PEP 340 redux
=
Syntax:
do EXPR [as VAR]:
BLOCK
Translation:
abc = EXPR
[VAR =] abc.__enter__()
try:
BLOCK
finally:
abc.__exit__(*sys.exc_info()) # Not exactly
Pros:
- can use a decorated generator as EXPR
- separation of EXPR and
Phillip J. Eby wrote:
At 08:41 AM 5/13/2005 -0700, Guido van Rossum wrote:
The 'oke' argument is so that the author of transactional() can decide
what to do with a non-local goto: commit, rollback or hit the author
over the head with a big stick.
snip
* Automatically roll back partially-done
[Guido van Rossum]
Cons:
- slightly less simple (__enter__ must return something for VAR;
__exit__ takes optional args)
[Fredrik Lundh]
what happened to the original yield the target object solution? or did
I just dream that?
Don't worry, that works when you use a generator. It just
[Guido van Rossum]
So then the all-important question I want to pose is: do we like the
idea of using a (degenerate, decorated) generator as a template for
the do-statement enough to accept the slightly increased complexity?
[Greg Ewing]
I can't see how this has anything to do with whether
Here's my vote on things at the moment:
+1 on
do EXPR as VAR:
...
+1 on keeping the EXPR and VAR distinct.
+1 on keeping the do and generator protocols distinct.
+1 on not going out of our way to let the controller
catch exceptions or alter control flow. Let's keep it
as simple as we
Guido van Rossum wrote:
BTW, we need a name for such a decorated generator that only yields
once. I propose to call it a degenerator.
Cute, but 'template generator' may be clearer (that's what I've been calling
them so far, anyway). Then 'iterator generator' can be used to explicitly refer
to
[Greg Ewing]
-0.7 on directly giving generators do-protocol methods.
I'm -1 on this myself.
I'm not yet convinced that encouraging people to use
generators to implement block controllers is a good
idea. If we blur the distinction too much at this
stage, we may regret it later if we come up
On 5/11/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I realize that the pushback was against looping, but whereas in the
PEP 340 proposal general exception handling comes out naturally, it
feels as an ugly wart in the modified PEP 310 proposal.
Plus I think the use cases are much weaker
On Wed, 11 May 2005, Guido van Rossum wrote:
[Steven Bethard]
exc = ()
try:
try:
BLOCK1
except:
exc = sys.exc_info()
finally:
stmt_exit(*exc)
would this make any of the examples impossible to write? All you have
to
Steven Bethard wrote:
On 5/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
The gist is that the alternative is to require an __exit__() method to raise
TerminateBlock in order to suppress an exception.
So I didn't see any examples that really needed TerminateBlock to
suppress an exception.
A quick response to various small issues...
- Benji York proposes that file and lock objects (for example) could
have suitable __enter__ and __exit__ methods (__enter__ would have
to return self). Right!
- Greg Ewing (I believe) wants 'do' instead of 'with' for the
keyword. I think I
I think this is my first post to python-dev, so a mini-intro: I've
been lurking here for about 5 years, professional user a bit longer,
now working at Zope Corp.
Guido van Rossum wrote:
Going for all-out simplicity, I would like to be able to write these examples:
class locking:
def
On 5/12/05, Benji York [EMAIL PROTECTED] wrote:
if the file object had these methods:
def __enter__(self): return self
def __exit__(self, *args): self.close()
you could write
do file('whatever) as f:
lines = f.readlines()
Or a lock:
def __enter__(self): self.aquire(); return
Guido van Rossum wrote:
Going for all-out simplicity, I would like to be able to write these examples:
class locking:
def __init__(self, lock): self.lock = lock
def __enter__(self): self.lock.acquire()
def __exit__(self, *args): self.lock.release()
class opening:
def
[Shane Hathaway]
If it's this simple, it should be possible to write something that
combines the acquisition of multiple resources in a single statement.
For example:
with combining(opening(src_fn), opening(dst_fn, 'w')) as src, dst:
copy(src, dst)
Yeah (and I don't see
Guido van Rossum wrote:
- Greg Ewing (I believe) wants 'do' instead of 'with' for the
keyword. I think I like 'with' better, especially combining it with
Benji's proposal. IMO this reads better with 'with' than with 'do':
with open(/etc/passwd) as f:
for line in f:
Michele Simionato wrote:
let lock:
do_something
let open(myfile) as f:
for line in f: do_something(line)
This is getting even further into the realm
of gibberish to my ear.
let f=file(myfile) :
for line in f: do_something(line)
To anyone with a Lisp or funcional background,
Phillip J. Eby wrote:
Of course, it's not *really* that simple, because __try__ doesn't exactly
correspond to 'try:', and it has to return something, but it sure is
simpler than the mental gymnastics I'd go through to convert
except/else/finally into if statements inside an __exit__.
You
On 5/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
I've posted draft 1.4 of my PEP 310/PEP 340 merger PEP (PEP 650, maybe?):
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
I've been skipping the discussion, but this is starting to look pretty
good. I'll give it a proper read soon.
[Guido]
Now it would make more sense to change the syntax to
with EXPR as VAR:
BLOCK
and we have Phillip Eby's proposal.
[Greg]
Change the 'with' to 'do' and I'd be +1 on this.
Great! But the devil is in the details. I want to reduce the
complexity, and I'm
[Phillip J. Eby]
FYI, there are still use cases for clearing the exception state in an
__exit__ method, that might justify allowing a true return from __exit__ to
suppress the error. e.g.:
[...]
Yes, but aren't those written clearer using an explicit try/except?
IMO anything that actually
At 10:42 AM 5/11/2005 -0700, Guido van Rossum wrote:
[Phillip J. Eby]
FYI, there are still use cases for clearing the exception state in an
__exit__ method, that might justify allowing a true return from __exit__ to
suppress the error. e.g.:
[...]
Yes, but aren't those written clearer
[Phillip J. Eby]
FYI, there are still use cases for clearing the exception state in an
__exit__ method, that might justify allowing a true return from __exit__
to
suppress the error. e.g.:
[...]
[Guido]
Yes, but aren't those written clearer using an explicit try/except?
IMO
Phillip J. Eby wrote:
FYI, there are still use cases for clearing the exception state in an
__exit__ method, that might justify allowing a true return from __exit__ to
suppress the error. e.g.:
Maybe __exit__ could suppress exceptions using a new idiom:
def __exit__(self,*exc):
At 12:44 PM 5/11/2005 -0600, Shane Hathaway wrote:
Phillip J. Eby wrote:
FYI, there are still use cases for clearing the exception state in an
__exit__ method, that might justify allowing a true return from
__exit__ to
suppress the error. e.g.:
Maybe __exit__ could suppress exceptions
Paul Moore wrote:
At the very least, there should be a section in rejected
alternatives explaining why it is not appropriate to force reraising
of exceptions unless explicit action is taken. There could be good
reasons (as I say, I haven't followed the discussion) but they should
be recorded.
Paul Moore wrote:
PS Apologies if I missed the discussion of this in the PEP - as I say,
I've only skimmed it so far.
With Guido's latest comments, it looks like this is going to be going into the
Open Issues section - his current inclination is that do statements should
only abstract finally
[Nick Coghlan]
With Guido's latest comments, it looks like this is going to be going into the
Open Issues section - his current inclination is that do statements should
only abstract finally clauses, not arbitrary exception handling. I believe
he's
misinterpreting the cause of the pushback
On 5/11/05, Nick Coghlan [EMAIL PROTECTED] wrote:
The gist is that the alternative is to require an __exit__() method to raise
TerminateBlock in order to suppress an exception.
So I didn't see any examples that really needed TerminateBlock to
suppress an exception. If the semantics of a
On 5/11/05, Steven Bethard [EMAIL PROTECTED] wrote:
If you want the default to be that the exception gets re-raised
(instead of being suppressed as it is above), I think you could just
change the finally block to something like:
finally:
if stmt_exit(*exc):
raise
[Steven Bethard]
So I didn't see any examples that really needed TerminateBlock to
suppress an exception. If the semantics of a do-statement was simply:
stmt = EXPR1
try:
stmt_enter = stmt.__enter__
stmt_exit = stmt.__exit__
except AttributeError:
[Guido]
Going for all-out simplicity, I would like to be able to write these examples:
class locking:
def __init__(self, lock): self.lock = lock
def __enter__(self): self.lock.acquire()
def __exit__(self, *args): self.lock.release()
class opening:
def __init__(self,
Guido van Rossum wrote:
class locking:
def __init__(self, lock): self.lock = lock
def __enter__(self): self.lock.acquire()
def __exit__(self, *args): self.lock.release()
class opening:
def __init__(self, filename): self.filename = filename
def __enter__(self): self.f =
On May 9, 2005, at 21:58, Guido van Rossum wrote:
Apologies if this has been discovered and rejected already; I've had
to skip most of the discussions but this though won't leave my head...
Skimming rather than skipping all of the discussion burned most of my
py-dev time, and it was just
At 07:57 AM 5/10/2005 -0700, Alex Martelli wrote:
On May 9, 2005, at 21:58, Guido van Rossum wrote:
But what if we changed the translation slightly so that VAR gets
assigned to value of the __enter__() call:
abc = EXPR
VAR = abc.__enter__() # I don't see why it
[Alex]
I like this. The only aspect of other proposals that I would sorely
miss here, would be the inability for abc.__exit__ to deal with
exceptions raised in BLOCK (or, even better, a separate specialmethod
on abc called in lieu of __exit__ upon exceptions). Or am I missing
something, and
Guido van Rossum wrote:
I used to dislike this, but the opposition and the proliferation of
alternative proposals have made me realize that I'd rather have this
(plus continue EXPR which will be moved to a separate PEP once I
have some extra time) than most of the other proposals.
Draft 1.3
[Phillip J. Eby]
Yeah, I'd ideally like to see __try__, __except__, __else__, and
__finally__ methods, matching the respective semantics of those clauses in
a try/except/finally block.
What's your use case for adding this complexity? I'm going for simple
here unless there's a really strong use
Guido van Rossum wrote:
[Nick]
Is that use case strong enough to require the added complexity? For a
transactional wrapper, I can see that __exit__ needs to know about
exceptions (though I'm unsure how much detail it needs), but what's
the point of being able to tell an exception from a
Nick Coghlan wrote:
Draft 1.3 of my PEP 310/PEP 340 merger is now up for public consumption:
http://members.iinet.net.au/~ncoghlan/public/pep-3XX.html
This draft was meant to drop the idea of __enter__() raising TerminateBlock
preventing execution of the statement body. I dropped it out of the
At 08:51 AM 5/10/2005 -0700, Guido van Rossum wrote:
[Phillip J. Eby]
Yeah, I'd ideally like to see __try__, __except__, __else__, and
__finally__ methods, matching the respective semantics of those clauses in
a try/except/finally block.
What's your use case for adding this complexity?
It
Guido van Rossum wrote:
Now it would make more sense to change the syntax to
with EXPR as VAR:
BLOCK
and we have Phillip Eby's proposal.
Change the 'with' to 'do' and I'd be +1 on this.
--
Greg Ewing, Computer Science Dept, +--+
Apologies if this has been discovered and rejected already; I've had
to skip most of the discussions but this though won't leave my head...
So PEP 310 proposes this:
with VAR = EXPR:
BLOCK
translated to
VAR = EXPR\
if hasattr(VAR, __enter__):
55 matches
Mail list logo
