On Fri, Apr 8, 2011 at 2:18 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Fri, 8 Apr 2011 10:11:34 -0700 Guido van Rossum <guido@python.org> wrote:
With apologies for not reading the PEP or this thread in full, some comments:
- I really like the syntax "except <exc> [as <var>] [if <test>]:". This addresses a pretty common use case in my experience. I don't care for the alternate proposed syntax that started this thread. I'm not sure that the 'if' subclause makes sense without the 'as' subclause, since most likely you'd want to refer to the caught exception. I note that it is more powerful than putting "if not <test>: raise" in the body of the except-clause, because it will allow subsequent except clauses to match still. I also note that it is a much "cleaner" change than (again) reorganizing the exception hierarchy, since there is no backward compatibility to consider.
My main issue with said new syntax is that it doesn't make things much easier to write. You still have to type an explicit condition, and remember the appropriate errno mnemonic for the situation. The very notion of "errno" and its plethora of abbreviated error codes is ok for people used to C programming, but certainly alien to other programmers (how long does it take to remember that "file not found" is spelled "ENOENT"?).
The fact that exception messages typically indicate the errno *number*, not mnemonic, is an additional annoyance (errno numbers are not standardized and can vary from system to system).
It wouldn't be that difficult to customize the IOError and OSError reprs to display the errno mnemonic instead of a number, if that's an issue. I don't think it's fair to characterize errnos as only for C programmers. Some other language use errno mnemonics too, not just C and Python. It's a cross-language way of understanding certain kinds of error conditions, and as such it makes it a bit easier to do things. What this PEP does is introduce a language-specific exception hierarchy instead. I think it's a good idea, but it's not as clearly superior to errnos as you suggest. It's easier to remember the language-specific exception hierarchy if you don't have to deal with other languages that use errnos, but if you do, the situation is different.
- Regarding restructuring the exception tree, I don't think this needs to wait for Python 4. (We've done it several times during Python 2.) But it is very tricky to do it without breaking existing code, and I'm not sure that deprecations will help that much. E.g. if two exceptions A and B are currently not related via inheritance, and we were to make A a subclass of B, then in code of the form try: ... except B: ... except A: ... the except A clause would become unreachable. Maybe it's easier to propose small changes instead of trying to refactor a huge section of the exception tree?
Well, I fear that small changes will not lead us very far. We have to level the existing tree before adding new types, because otherwise it's not obvious where these new types should be grafted, since in practice OSError, IOError or socket.error can be used for very similar error conditions.
- Quite independently, I think it is time that we started documenting which exceptions are raised from standard APIs.
Agreed, and unit-test them too.
(But it may well define a new kind of "bad data" exception, and I don't think we need a common base class for all "bad data" or "bad state" exceptions.)
Isn't it ValueError actually? For example, closed files raise ValueError when you try to do an operation on them.
Regards
Antoine.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas