Movatterモバイル変換

[Python-Dev] Major revision of PEP 348 committed

• Previous message:[Python-Dev] Major revision of PEP 348 committed
• Next message:[Python-Dev] Major revision of PEP 348 committed
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

VMError -- This is a new intermediate grouping so it won't breakanything and it does bring together two exceptions relating them bysource.  However, I recommend against introducing this new group.Besides added yet another thing to remember, it violatesFlat-Is-Better-Than-Nested (see FIBTN below).  Also, the new group isshort on use cases with MemoryErrors sometimes being recoverable andSystemErrors generally not.  In the library, only cookielib catchesthese 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 issome recurring need to catch that group. EOFError -- I recommend leaving this one alone.  IOError is generallyfor real errors while EOF occurs in the normal course of reading a fileor filelike source.  The former is hard to recover and the latter isnormal.  The PEP's justification of "Since an EOF comes from I/O it onlymakes sense that it be considered an I/O error" is somewhat shallow anddoesn't reflect thought about how those exceptions are actually used.That information is readily attainable by scanning the standard librarywith 57 instances of EOFError and 150 instances of IOError.  There are afew cases of overlap where an except clause catches both; however, thetwo are mostly used independent from one another.  The review of thelibrary gives a good indication of how much code would be broken by thischange.  Also, see the FIBTN comment below.AnyDeprecationWarning -- This grouping makes some sense intuitively butdo we have much real code that has had occasion to catch both at thesame time?  If not, then we don't need this.   FIBTN (flat-is-better-than-nested) -- This bit of Zen carries extrasignificance for the exception hierarchy.  The core issue is thatexceptions are NOT inherently tree-structured.  Each may ultimatelycarry its own set of meaningful attributes and those tend to not neatlyroll-up into a parent/subclass relationships without Liskov violations.Likewise, it is a mistake to introduce nesting as a means ofcategorization.  The problem is that many conflicting, though meaningfulgroupings are possible.  (i.e. grouped by source (vm, user, data,system), grouped by recoverability or transience, grouped bymodule/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 aretypically all handled together.  IOW, any new nesting needs to bejustified by a long list of real code examples that currently catch allthose exceptions at the same time.  Ideally, searching for that listwould also turn-up no competing instances where other, orthogonalgroupings are being used.Vocabulary size -- At one time, python-dev exhibited a strong reluctanceto introduce any new builtins.  No matter how sensible the idea, therewas typically an immediate effort to jam the proposed function into someother namespace.  It should be remembered that each of PEP 348'sproposed new exception groupings ARE new builtins.  Therefore, the barfor admission should be relatively high (i.e. I would prefer Fredrik'sjoin() proposal to any of the above new proposals).   Every new word inthe vocabulary makes the language a little more complex, a little lesslikely to fit in your brain, and a little harder to learn.  Nestingsmake this more acute since learning the new word also entailsremembering how it fits in the structure (yet another good reason forFIBTN).Once again, my advice is not introduce change unless it is solving aspecific, real problem in existing code.  The groupings listed above feel like random ideas searching for ajustification rather than the product of an effort to solve knownissues.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 whichexceptions are typically caught on the same line.  That would be aworthwhile empirical study and may lead to useful insights.Try to avoid reversing the process, staring at the existing tree, andletting your mind arbitrarily impose patterns on it.  Raymond

• Previous message:[Python-Dev] Major revision of PEP 348 committed
• Next message:[Python-Dev] Major revision of PEP 348 committed
• Messages sorted by:[ date ][ thread ][ subject ][ author ]