Home Original page

[Python-ideas] PEP-3151 pattern-matching

Devin Jeanpierre jeanpierreda at gmail.com
Fri Apr 8 21:00:50 CEST 2011 
On Fri, Apr 8, 2011 at 2:18 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Fri, 8 Apr 2011 10:11:34 -0700
> Guido van Rossum <guido at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
More information about the Python-ideas mailing list