VMError -- This is a new intermediate grouping so it won't break anything and it does bring together two exceptions relating them by source. However, I recommend against introducing this new group. Besides added yet another thing to remember, it violates Flat-Is-Better-Than-Nested (see FIBTN below). Also, the new group is short on use cases with MemoryErrors sometimes being recoverable and SystemErrors generally not. In the library, only cookielib catches these and it does so along with KeyboardInterrupt in order to re-raise. In general, you don't want to introduce a new grouping unless there is some recurring need to catch that group.
EOFError -- I recommend leaving this one alone. IOError is generally for real errors while EOF occurs in the normal course of reading a file or filelike source. The former is hard to recover and the latter is normal. The PEP's justification of "Since an EOF comes from I/O it only makes sense that it be considered an I/O error" is somewhat shallow and doesn't reflect thought about how those exceptions are actually used. That information is readily attainable by scanning the standard library with 57 instances of EOFError and 150 instances of IOError. There are a few cases of overlap where an except clause catches both; however, the two are mostly used independent from one another. The review of the library gives a good indication of how much code would be broken by this change. Also, see the FIBTN comment below. AnyDeprecationWarning -- This grouping makes some sense intuitively but do we have much real code that has had occasion to catch both at the same time? If not, then we don't need this. FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extra significance for the exception hierarchy. The core issue is that exceptions are NOT inherently tree-structured. Each may ultimately carry its own set of meaningful attributes and those tend to not neatly roll-up into a parent/subclass relationships without Liskov violations. Likewise, it is a mistake to introduce nesting as a means of categorization. The problem is that many conflicting, though meaningful groupings are possible. (i.e. grouped by source (vm, user, data, system), grouped by recoverability or transience, grouped by module/container type (dictionary errors, weakref errors, net errors, warnings module, xml module, email errors), etc.) The ONLY useful nestings are those for a cluster of exceptions that are typically all handled together. IOW, any new nesting needs to be justified by a long list of real code examples that currently catch all those exceptions at the same time. Ideally, searching for that list would also turn-up no competing instances where other, orthogonal groupings are being used. Vocabulary size -- At one time, python-dev exhibited a strong reluctance to introduce any new builtins. No matter how sensible the idea, there was typically an immediate effort to jam the proposed function into some other namespace. It should be remembered that each of PEP 348's proposed new exception groupings ARE new builtins. Therefore, the bar for admission should be relatively high (i.e. I would prefer Fredrik's join() proposal to any of the above new proposals). Every new word in the vocabulary makes the language a little more complex, a little less likely to fit in your brain, and a little harder to learn. Nestings make this more acute since learning the new word also entails remembering how it fits in the structure (yet another good reason for FIBTN). Once again, my advice is not introduce change unless it is solving a specific, real problem in existing code. The groupings listed above feel like random ideas searching for a justification rather than the product of an effort to solve known issues. If the PEP can't resist the urge to create new intermediate groupings, then start by grepping through tons of Python code to find-out which exceptions are typically caught on the same line. That would be a worthwhile empirical study and may lead to useful insights. Try to avoid reversing the process, staring at the existing tree, and letting your mind arbitrarily impose patterns on it. Raymond _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
