Guido van Rossum <[EMAIL PROTECTED]> writes:
> [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 Ja
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 weak
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
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 exce
Well, I logged into Sourceforge with the idea of filing my feature request
about copying functions, and then my eye went on my previous submissions.
It seems it takes some time to fix non-critical bugs, isn't it? ;)
Two years ago, I discovered a bug with pydoc for classes containing "super"
objec
> > Can I go ahead and approve this now
>
> While I see the cost of this PEP being pretty small, I see the benefit
> the same way too.
Sure. Let me approve it and we'll see if someone cares enough to implement it.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
On 5/12/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Yeah, I figured out a tidier way to handle it after reading Phillip's message
> earlier today. My idea is similar to your second solution, but with an early
> exit via break, continue or return still indicated to the __exit__() method
> via
> T
On 5/12/05, Michele Simionato <[EMAIL PROTECTED]> wrote:
> In my experience super is a huge can of worms and actually I have a
> non-feature
> request about the descriptor aspect of super: I would like super's
> __get__ method
> and the possibily to call super with just one argument to be removed
In http://mail.python.org/pipermail/python-dev/2005-May/053652.html Nick wrote:
terminate = True
VAR1 = stmt_enter() # Omit 'VAR1 =' if no 'as' clause
try:
try:
BLOCK1
except TerminateBlock:
raise # Disallow suppression of TerminateBlock
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 like
On 5/12/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
>super doesn't work with "meta-attributes" and classmethods:
>
> py> super(C, C).__name__
> Traceback (most recent call last):
> File "", line 1, in ?
> AttributeError: 'super' object has no attribute '__name__'
Actually this is the Right Th
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:
> d
On 5/12/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> - Steve Bethard has this example:
>
> stmt = EXPR1
> VAR1 = stmt.__enter__()
> exc = () # or (None, None, None) if you prefer
> try:
> try:
> BLOCK1
> except:
> exc = sys.exc_info()
>
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.aq
At 07:50 AM 5/12/2005 -0700, Guido van Rossum wrote:
>- Paul Moore wants the generator templates to explicitly contain
> try/finally (or try/except, depending on the use case). That's much
> more work though (passing exceptions into a generator is a new
> feature) and is not necessary to get
[Guido van Rossum]
> >- Paul Moore wants the generator templates to explicitly contain
> > try/finally (or try/except, depending on the use case). That's much
> > more work though (passing exceptions into a generator is a new
> > feature) and is not necessary to get the "redux" version.
[Ph
> - Ka-ping Yee thinks we need separate entry points for the exceptional
> and the normal termination case. I disagree; this would end up in
> unnecessary duplication of code (or boilerplate to equate the two
> methods) in most cases. The whole *point* is that finally gets to
> do its cle
Here's another use case to think about.
Example 2: Replacing a File.
Suppose we want to reliably replace a file. We require that either:
(a) The file is completely replaced with the new contents;
or (b) the filesystem is unchanged and a meaningful exception is thrown.
We'd like to be able
At 03:00 PM 5/12/2005 -0500, Ka-Ping Yee wrote:
>This is all so intricate i'm not sure if i got it right. Somebody
>let me know if this looks right or not. (In any case, i look forward
>to the day when i can rely on someone else to get it right, and they
>only have to write it once!)
It looks fi
[Ka-Ping Yee]
> Example 1: Exception Chaining.
>
> As has been previously discussed, the information from an exception can
> be lost when the handling of the exception runs into a problem. It is
> often helpful to preserve the original reason for the problem.
[example deleted]
This problem is un
On Thu, 12 May 2005, Guido van Rossum wrote:
> [Ka-Ping Yee]
> > Example 1: Exception Chaining.
> >
> > As has been previously discussed, the information from an exception can
> > be lost when the handling of the exception runs into a problem. It is
> > often helpful to preserve the original reaso
Phillip J. Eby wrote:
> Really, the only use case for suppressing exceptions is to, well, suppress
> exceptions that are being logged, shown to the user, sent via email, or
> just plain ignored. Guido's point, I think, is that these use cases are
> rare enough (yet simple and similar enough) th
It occurred to me as i was messing around with handling and re-raising
exceptions that tossing around these (type, value, traceback) triples
is irritating and error-prone.
How about just passing around a single value? All we'd have to do is
put the traceback in value.traceback.
Implementation:
Suppose exceptions have an optional "context" attribute, which is
set when the exception is raised in the context of handling another
exception. Thus:
def a():
try:
raise AError
except:
raise BError
yields an exception which is an instance of BError.
[Ka-Ping Yee]
> It occurred to me as i was messing around with handling and re-raising
> exceptions that tossing around these (type, value, traceback) triples
> is irritating and error-prone.
>
> How about just passing around a single value? All we'd have to do is
> put the traceback in value.tra
[Ka-Ping Yee]
> Suppose exceptions have an optional "context" attribute, which is
> set when the exception is raised in the context of handling another
> exception. Thus:
>
> def a():
> try:
> raise AError
> except:
> raise BError
>
> yields an excepti
Guido van Rossum wrote:
> [Ka-Ping Yee]
>
>>It occurred to me as i was messing around with handling and re-raising
>>exceptions that tossing around these (type, value, traceback) triples
>>is irritating and error-prone.
>>
>>How about just passing around a single value? All we'd have to do is
>>p
Guido van Rossum wrote:
> [Ka-Ping Yee]
>
>>Suppose exceptions have an optional "context" attribute, which is
>>set when the exception is raised in the context of handling another
>>exception. Thus:
>>
>>def a():
>>try:
>>raise AError
>>except:
>>raise
On Thu, 12 May 2005, Brett C. wrote:
> Guido van Rossum wrote:
> > Try to come up with a precise specification and we'll talk.
>
> If a new exception is raised (e.g., not a bare 'raise') while a current
> exception is active (e.g., sys.exc_info() would return something other
> than a tuple of None)
[Brett C.]
> If a new exception is raised (e.g., not a bare 'raise') while a current
> exception is active (e.g., sys.exc_info() would return something other than a
> tuple of None), then the new exception is made the active exception and the
> now
> old exception is assigned to the new exception'
[Brett C.]
> Seems like, especially if we require inheritance from a base exception class
> in
> Python 3000, exceptions should have standard 'arg' and 'traceback' attributes
> with a possible 'context' attribute (or always a 'context' attribute set to
> None if not a chained exception).
>
> I do
On Thu, 12 May 2005, Guido van Rossum wrote:
> Define "raise". Does that involve a raise statement?
Not necessarily; it could be a raise statement or an inadvertently
triggered exception, such as in the example code i posted.
> What about 1/0?
That counts.
> What if you call a method that execu
On Thu, 12 May 2005, Brett C. wrote:
> whether bare 'except' statements should go or only catch certain exceptions.
Maybe bare 'except' should be spelled 'except *'.
I don't think it can be removed altogether because sometimes you just
need to be able to do magic, but it can be made a little more
At 07:36 PM 5/12/2005 -0500, Ka-Ping Yee wrote:
>On Thu, 12 May 2005, Brett C. wrote:
> > Guido van Rossum wrote:
> > > Try to come up with a precise specification and we'll talk.
> >
> > If a new exception is raised (e.g., not a bare 'raise') while a current
> > exception is active (e.g., sys.exc_
[Ka-Ping Yee]
> Maybe bare 'except' should be spelled 'except *'.
-1.
> I don't think it can be removed altogether because sometimes you just
> need to be able to do magic, but it can be made a little more explicit.
Assuming a single root of the exception tree, you can spell it
explicitly as "ex
On Thu, 12 May 2005, Guido van Rossum wrote:
> How is "except:" less greppable?
Duh. I'm slow today.
-- ?!ng
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
[Phillip J. Eby]
> I think the main problem is going to be that (IIUC), Python doesn't "know"
> when you've exited an 'except:' clause and are therefore no longer
> handling the exception.
But the compiler knows and could insert code to maintain this state.
> sys.exc_info() still gives you the e
[Guido]
> > What if that method catches that exception?
[Ka-Ping Yee]
> Did you mean something like this?
>
> def handle():
> try:
> open('spamspamspam')
> except:
> catchit()
> # point A
> ...
>
> def catchit():
> t
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:
>
On May 12, 2005, at 6:32 PM, Ka-Ping Yee wrote:
> Suppose exceptions have an optional "context" attribute, which is
> set when the exception is raised in the context of handling another
> exception. Thus:
>
> def a():
> try:
> raise AError
> except:
> r
[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 an
James Y Knight wrote:
> Of course you can already do similar with current python, it just
> can't be spelled as nicely, and the default traceback printer won't
> use the info:
>
> try:
>raise AError
> except:
>newException = BError()
>newException.cause=sys.exc_info()
>raise newEx
[James Y Knight ]
> I think it's a bad idea to have this happen automatically. Many times
> if an exception is raised in the except clause, that doesn't
> necessarily imply it's related to the original exception. It just
> means there's a bug in the exception handler.
Yeah, but especially in that
All this talk about try: ... finally: and exceptions reminded me of a curious
behavior I discovered a while back, i.e. that finally can swallow
your exceptions. This is a contrived example, but shows the point:
def divide1(n1, n2):
try:
result = n1/n2
finally:
print "clean
Michele Simionato wrote:
> def divide1(n1, n2):
> try:
> result = n1/n2
> finally:
> print "cleanup"
> result = "Infinity\n"
> return result # the exception is swallowed away
What would you prefer to have happen in this case?
Or do you think return (and b
Guido van Rossum wrote:
> It won't fly as long as we have string exceptions (since there's
> nowhere to put the traceback) but once those are dead I like it a lot.
Are there plans as to when string exceptions will be
exterminated? Surely the only places they're used now
are in some very old librar
Brett C. wrote:
> Seems like, especially if we require inheritance from a base exception class
> in
> Python 3000, exceptions should have standard 'arg' and 'traceback' attributes
> with a possible 'context' attribute (or always a 'context' attribute set to
> None if not a chained exception).
In
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 ba
On 5/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Michele Simionato wrote:
>
> > def divide1(n1, n2):
> > try:
> > result = n1/n2
> > finally:
> > print "cleanup"
> > result = "Infinity\n"
> > return result # the exception is swallowed away
>
> What would
It did surprise me also. Because I've come to Python from Delphi.
There are no return statement in Delphi.
I also write some c++, the language has no finally-statement. This
problem probably python exclusive.
I think it's not too difficult to get used to it. This behavior is fine
for me.
___
51 matches
Mail list logo
