[Python-ideas] PEP 3151: Reworking the OS and IO exception hierarchy

[Mike Meyer]

On Sat, 24 Jul 2010 11:16:45 +0400
Ivan Pozdeev <vano at mail.mipt.ru> wrote:

> As a user you are talking about in the PEP, i'm quite satisfied with the current implementation.

As a user, I'm also quite satisfied with the current implementation,
but think the proposal would be a major improvement in all areas.

> I strongly oppose introducing 'fine-grained' exceptions.

I think we see this in two different ways. The current version of the
PEP seems to be somewhere between the two views. But in particular:

> Adding errno-specific subexceptions

I didn't see the PEP as calling for that. I saw it as dividing up the
new combined IOError/OSError/EnvironmentError into finer-grained
groups that make logical sense together. Yes, that division would
depend on errno, and some of the groups on some platforms may well
have only one errno - indeed, the first pass had a lot of those - but
that's an implementation detail.

> 1) makes some errnos privileged at the expense of others

Well, some are privileged, in that they now belong to a finer
grouping. I don't see how it's at the "expense" of the others: you can
still catch the upper-level one and sort on errno, just like you do
now.

> 2) introduces a list that isn't bound to any objective characteristic and is just an
> arbitrary "favorites" list

That I would object to. I expect the PEP to include objective rules
for each subgroup that can be used to determine if an errno belongs in
that subgroup.

> 3) adds types that characterize single errors rather than error
> classes which is an unnecessary level of complexity.

That actually sounds like the way most packages do things.

> 3))
> Builtin I/O operations throw IOError, OS function wrappers throw
> OSError, package functions throw package-specific ones -
> quite obvious where to expect which.

If only practice matched theory. Package functions throw
package-specific exceptions, but they also call functions that can
throw OS or IO errors.  So in practice, I find I often have to deal
with those as well as the package-specific ones. I can't even say the
package authors are wrong not to catch and map those errors into
package-specific errors.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org