Nick Coghlan wrote: > Martin v. Löwis wrote: >> Alex Martelli wrote: >> I think the standard exception hierarchy should grow additional standard >> fields. E.g. AttributeError should have attributes 'type','name', or >> perhaps even 'object','name'. TypeError should have attributes >> 'expected', 'actual' (or, again, 'expected', 'object'). > >> And so on - that might produce quite a large PEP. > > I don't think there's any reason to do it in one big bang. And > approached individually, each such alternate constructor is a small RFE > consisting of: > > 1. Specific C API for creating exceptions of that type with a standard > message and attributes > 2. Python level class method > 3. New attributes on the affected object > > Point 3 would be optional really, since most of the gain comes from the > better error messages. If extra attributes were included in such an RFE, > the potential lifecycle implications of including references to actual > objects rather than merely their types makes the better choice fairly > obvious to me (i.e. just include the type information, since it > generally tells you everything you need to know for TypeErrors and > AttributeErrors). > >> As 3.0 missed the >> chance to fix this, compatibility is also an issue. It might be possible >> to overload exception constructors on the number of parameters, or using >> keyword parameters for the new way of filling the exception. > > Or go the traditional "multiple constructor" route and provide class > methods for the alternative mechanisms. > Bear in mind, though, that as new functionality none of this can go in before 3.1/2.7. So a PEP might not be a bad idea if only to establish best practices.
regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ _______________________________________________ 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
