Paul Moore wrote:
Unfortunately, I don't have a better naming suggestion (other than
simply template, which is probably too general to work), so I just
raise this as something you should expect to need to clarify a few
times...
PEP 346 used statement_template for the generator decorator. That
On 6/1/05, Guido van Rossum [EMAIL PROTECTED] wrote:
I hope that I've got the rewrite of PEP 343 to include generator
extensions right now. I've chosen the 'with' keyword. Please review
here; I think this is ready for review by the unwashed masses. :-)
Guido van Rossum wrote:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
I just realized this has a race condition. The bytecode for the
expression closing(open(...)) must necessarily contain a bytecode
that calls open() followed by
On 6/5/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
I just realized this has a race condition. The bytecode for the
expression closing(open(...)) must
Guido van Rossum wrote:
[Phillip J. Eby]
* The transaction handler could also be written as:
@with_template
def transactional(db):
db.begin()
try:
yield db
except:
db.rollback()
else:
db.commit()
at least, if I
Arnold deVos wrote:
This template eats eats the exception, which will cause a RuntimeError
in the proposed Wrapper, I think. A raise after rollback is needed.
Actually, the Wrapper as written in the PEP does not raise RuntimeError
if the generator catches a block's exception.
Shouldn't the
[Arnold deVos, responding to himself]
This template eats eats the exception, which will cause a RuntimeError
in the proposed Wrapper, I think. A raise after rollback is needed.
No, the generator returns after rolling back, which causes throw() to
raise StopIteration, which is good enough for
[me]
I'll summarize this discussion in the PEP.
I've added this section to the PEP. Is anyone dead set against the
tentative resolutions here?
Open Issues
Discussion on python-dev has revealed some open issues. I list
them here, with my preferred resolution and its motivation. The
Guido van Rossum wrote:
I hope that I've got the rewrite of PEP 343 to include generator
extensions right now. I've chosen the 'with' keyword. Please review
here; I think this is ready for review by the unwashed masses. :-)
http://www.python.org/peps/pep-0343.html
Looks pretty good to
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
+1 if you make it 'if hasattr(obj,close):
On 6/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
At 09:20 AM 6/2/2005 -0700, Guido van Rossum wrote:
On 6/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:08 AM 6/3/2005 +1000, Nick Coghlan wrote:
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
Phillip J. Eby wrote:
At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote:
Phillip J. Eby wrote:
-1, too confusing.
A matter of taste, I guess. IMHO 'with' secretly handling exceptions
is
confusing.
It doesn't secretly handle them; it simply gets access to them, which
is an entirely
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles uncaught
exceptions by forwarding it to EXPR's __exit__ method. No confusion with me.
No doubt. However, it's not obvious what happens to an exception in EXPR;
surely it can't be
On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
uncaught exceptions by forwarding it to EXPR's __exit__ method. No
confusion with me.
No doubt. However, it's not obvious
At 10:16 PM 6/2/2005 +0200, Eric Nieuwland wrote:
On 2 jun 2005, at 22:12, Phillip J. Eby wrote:
At 10:04 PM 6/2/2005 +0200, Eric Nieuwland wrote:
I was thinking about 'try EXPR [as VAR]:' as a 'try' that handles
uncaught exceptions by forwarding it to EXPR's __exit__ method. No
Phillip J. Eby wrote:
That's not a bug, it's a feature. If the object doesn't have a
'close()'
method, clearly it doesn't need to be closed. If it's the wrong
object
for what you're using it for in the body of the 'with' block, it'll
show up
there, so this doesn't hide any errors.
[Nick Coghlan]
Also, I'm wondering if it would be useful to have a 'closing' template
that looked like:
@with_template
def closing(obj):
try:
yield obj
finally:
obj.close()
That can be used to deterministically close anything with a close
Guido van Rossum wrote:
[...] a generator doing cleanup depending on the
exception thrown (like the transactional() example below) can
*catch* the exception thrown if it wants to and doesn't have to
worry about re-raising it. I find this more convenient for the
http://www.python.org/peps/pep-0343.html
I should add that IMO this obsoletes PEP 288 and PEP 325; I plan to
reject those when PEP 343 is accepted. I've already withdrawn PEP 340.
PEP 342 is separate (but I'll probably present it together with PEP
343).
--
--Guido van Rossum (home page:
At 08:16 AM 6/1/2005 -0700, Guido van Rossum wrote:
I hope that I've got the rewrite of PEP 343 to include generator
extensions right now. I've chosen the 'with' keyword. Please review
here; I think this is ready for review by the unwashed masses. :-)
http://www.python.org/peps/pep-0343.html
[Guido van Rossum]
http://www.python.org/peps/pep-0343.html
[Phillip J. Eby]
Looks great. A few questions/comments:
* What's the rationale for raising TypeError from close()? Wasn't
RuntimeError discussed previously for that role? (and it's also used by
the with_template example)
Nice going! But ...
Could we extend the 'try' syntax for this instead of introducing
'with'? If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
could then be translated to
abc = EXPR
Eric Nieuwland wrote:
If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
Oops, that should read:
try EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote:
Nice going! But ...
Could we extend the 'try' syntax for this instead of introducing
'with'? If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
Phillip J. Eby wrote:
At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote:
If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
could then be translated to
-1, too confusing.
A matter of taste,
At 10:00 PM 6/1/2005 +0200, Eric Nieuwland wrote:
Phillip J. Eby wrote:
At 08:46 PM 6/1/2005 +0200, Eric Nieuwland wrote:
If I look at the translation it an augmented 'try'.
with EXPR as VAR:
BLOCK1
except EXCEPTION:
BLOCK2
could then
27 matches
Mail list logo
