[Brett]

This obviously goes against what Guido last said he wanted, but I hope I can convince him to get rid of bare 'except's.

-1 on eliminating bare excepts. This unnecessarily breaks tons of code without offering ANY compensating benefits. There are valid use cases for this construct. It is completely Pythonic to have bare keywords apply a useful default as an aid to readability and ease of coding. +1 on the new BaseException +1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt. -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except TerminatingException". 1) Grepping existing code bases shows that these two are almost never caught together so it is a bit silly to introduce a second way to do it. 2) Efforts to keep the builtin namespace compact argue against adding a new builtin that will almost never be used. 3) The change unnecessarily sacrifices flatness, making the language more difficult to learn. 4) The "self-documenting" rationale is weak -- if needed, a two-word comment would suffice. Existing code almost never has had to comment on catching multiple exceptions -- the exception tuple itself has been sufficiently obvious and explicit. This rationale assumes that code readers aren't smart enough to infer that SystemExit has something to do with termination. Raymond

...

It is completely Pythonic to have bare keywords apply a useful default as an aid to readability and ease of coding.

[Oleg]

Bare "while:" was rejected because of "while WHAT?!". Bare "except:" does not cause "except WHAT?!" reaction. Isn't it funny?! (-:

It's both funny and interesting. It raises the question of what makes the two different -- why is one instantly recognizable and why does the other trigger a gag reflex. My thought is that bare excepts occur in a context that makes their meaning clear: try: block() except SpecificException: se_handler() except: handle_everything_else() The pattern of use is similar to a "default" in a switch-case construct. Viewed out-of-context, one would ask "default WHAT". Viewed after a series of case statements, the meaning is vividly clear. Raymond

I'm with Raymond here. On 8/15/05, Raymond Hettinger wrote:

[Brett]

...

This obviously goes against what Guido last said he wanted, but I hope I can convince him to get rid of bare 'except's.

-1 on eliminating bare excepts. This unnecessarily breaks tons of code without offering ANY compensating benefits. There are valid use cases for this construct. It is completely Pythonic to have bare keywords apply a useful default as an aid to readability and ease of coding.

+1 on the new BaseException

+1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt.

-1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except TerminatingException". 1) Grepping existing code bases shows that these two are almost never caught together so it is a bit silly to introduce a second way to do it. 2) Efforts to keep the builtin namespace compact argue against adding a new builtin that will almost never be used. 3) The change unnecessarily sacrifices flatness, making the language more difficult to learn. 4) The "self-documenting" rationale is weak -- if needed, a two-word comment would suffice. Existing code almost never has had to comment on catching multiple exceptions -- the exception tuple itself has been sufficiently obvious and explicit. This rationale assumes that code readers aren't smart enough to infer that SystemExit has something to do with termination.

Raymond

_______________________________________________ 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/guido%40python.org

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

On 8/15/05, Toby Dickenson wrote:

On Monday 15 August 2005 14:16, Raymond Hettinger wrote:

...

-1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except TerminatingException".

The rationale for including TerminatingException in the PEP would also be satisfied by having a TerminatingExceptions tuple (in the exceptions module?). It makes sense to express the classification of exceptions that are intended to terminate the interpreter, but we dont need to express that classification as inheritence.

While the idea is fine, I just know that the point is going to be brought up that the addition should not be done until experience with the new hierarchy is had. I will add a comment that tuples can be added to the module after enough experience is had, but I am not going to try pushing for this right now. Of course I could be surprised and everyone could support the idea. =) -Brett

On 8/15/05, Scott David Daniels wrote:

An argument _for_ TerminatingException as a class is that I can define my own subclasses of TerminatingException without forcing it to being a subclass of KeyboardInterrupt or SystemExit.

And how would that help you? Would your own exceptions be more like SystemExit or more like KeyboardInterrupt, or neither? If you mean them to be excluded by base "except:", you can always subclass BaseException, which exists for this purpose. -- --Guido van Rossum (home page: http://www.python.org/~guido/)