[Python-Dev] Attribute error: providing type name (original) (raw)

Steve Holden steve at holdenweb.com
Wed Dec 3 04:39:23 CET 2008

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/

More information about the Python-Dev mailing list