Guido van Rossum wrote:
The point is not to avoid bare 'except:' from hiding programming
errors. There's no hope to obtain that goal.
The point is to make *legitimate* uses of bare 'except:' easier -- the
typical use case is an application that has some kind of main loop
which uses bare
The title is perhaps a little too grandiose but it's the best I
could think of. The change is really not large. Personally, I
would be happy enough if only %s was changed and the built-in was
not added. Please comment.
Neil
PEP: 349
Title: Generalised String Coercion
Version: $Revision:
[Nick Coghlan]
As others have pointed out, GeneratorExit and StopIteration should
never
reach
the job execution loop - if they do, there's a bug in the job, and
they
should
be caught and logged.
Please read my other, detailed post on this (8/5/2005 4:05pm). It is a
mistake to bypass control
A.M. Kuchling wrote:
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the exception arguments are
long or include string formatting, you don't need to use line
On 8/6/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the exception arguments are
long or include string formatting, you
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the exception arguments are
long or include string formatting, you don't need to use line
continuation characters
[AMK]
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the exception arguments are
long or include string formatting, you don't need to use line
continuation characters
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 8/6/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better,
PEP: 349
Title: Generalised String Coercion
...
Rationale
Python has had a Unicode string type for some time now but use of
it is not yet widespread. There is a large amount of Python code
that assumes that string data is represented as str instances.
The long term plan for
On 8/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 8/6/05, A.M. Kuchling [EMAIL PROTECTED] wrote:
PEP 8 doesn't express any preference between the
two forms of raise statements:
raise ValueError, 'blah'
raise ValueError(blah)
I like the second form better, because if the
[Removed python-list CC]
On 8/6/05, Terry Reedy [EMAIL PROTECTED] wrote:
PEP: 349
Title: Generalised String Coercion
...
Rationale
Python has had a Unicode string type for some time now but use of
it is not yet widespread. There is a large amount of Python code
that assumes
The remainder of my message then goes on to describe a hierarchy just
as
you
suggest - SystemError, MemoryError, StopIteration and GeneratorExit
are
all
still caught by except Exception:. The only two exceptions which are
no
longer caught by except Exception: are KeyboardInterrupt and
Version 1.5 of PEP 348 (http://www.python.org/peps/pep-0348.html) just
got checked in. This one is a *big* change compared to the previous
version:
* Renamings removed
* SystemExit are the KeyboardInterrupt are the only exceptions *not*
inheriting from Exception
+ CriticalException has been
13 matches
Mail list logo
