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.
thanx and regards
duraivel
___
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/archive%40mail-archive.com
[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
In setobject.c rev 1.26 + 1.27 Raymond removed gc support from built-in
set objects, claiming in the log message that sets cannot have
cycles. Yet the attached program creates a cycle that I don't believe
ever gets reclaimed.
Patch 1200018 restores GC support to set objects for Python 2.4.
[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
In article [EMAIL PROTECTED],
Timothy Fitz [EMAIL PROTECTED] wrote:
No, as except clauses can only occur before the finally clause, and
execution
should not go backwards.
This restriction feels a bit arbitrary. I can guarantee someone is
going to flatten this:
try:
try:
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
[Steven Bethard]
I have a feeling that it might actually be easier to continue to
document try/except and try/finally separately and then just give the
semantics of try/except/finally in terms of the other semantics. Take
a look at the Java Language Specification[1] (pages 399-401) if you
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 =
20 matches
Mail list logo
