[Python-ideas] PEP-3151 pattern-matching

[Guido van Rossum]

On Fri, Apr 8, 2011 at 11:18 AM, 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.

As I explained in other messages, it also adds semantics that are not
so easily emulated with the existing syntax (you'd have to repeat code
or use nested try/except blocks).

> 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"?).

Well, this is a fact of life. There are hundreds of errno codes and
they vary across systems, both in names and in numbers (even if there
is a handful that exist nearly everywhere and almost always have the
same values). This is the nature of system calls, and some operating
systems just have a richer set of error conditions that they present
to the (advanced) programmer.

If you are careful you can probably come up with a few handfuls of
common error conditions for which it makes sense to introduce new
exceptions that are defined (and presumably raised) on all platforms.
"File not found" is one of those. But there are always error
conditions that are not in this list, and we would still need the
errno attribute and the errno module to map between numbers, names and
messages in the general case. And occasionally some programmer needs
to select behaviors depending on the precise errno value.

> 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).

That would seem to be a problem with the str() and/or repr() of
OSError, and perhaps we can fix it there.

>> - 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.

Alas, you are right, they are all essentially the same thing but
raised by different operations (sometimes it's even the same
underlying system call, e.g. os.write vs. stream.write).

>> - 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.

No, there are lots of other exceptions indicating "bad arguments" or
"bad data" or "bad state" that don't derive from ValueError, from
KeyError to binhex.Error (a random example I picked from the stdlib).

-- 
--Guido van Rossum (python.org/~guido)