[Python-Dev] Attribute error: providing type name
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