On Sat, 24 Jul 2010 11:16:45 +0400 Ivan Pozdeev <vano@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@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