exception question

[Alex Martelli]

Aahz wrote:

> In article <lfp4lv8krqakeea3d0k0tcm86mb2mnf2v3 at 4ax.com>,
> Gonçalo Rodrigues  <op73418 at mail.telepac.pt> wrote:
>>
>>For error processing I found convenient maintaining a dictionary where
>>the keys are exception *classes* and the values are callables. Of
>>course, for this to work, exception classes have to be hashable which
>>I happily found that they were. So my question is, can I count on this
>>behaviour? Or is this behaviour I should not count on? (I found
>>nothing on the docs about it, thus the question).
> 
> If it's not documented, you can't count on it.  There's no intrinsic
> reason exception classes would be made unhashable, *but* classes become
> unhashable as soon as they implement __cmp__() or __eq__() *and* they
> fail to implement __hash__().  So if someone ever asks to compare
> exceptions, it could be an issue.

A new-style class would NOT become unhashable by implementing __eq__
w/o __hash__, although its INSTANCES would (but Gonçalo is clearly
indicating that he cares about classes, not instances).  Unfortunately
exception classes are old-style, so they'd be subject to the darned
old confusion between class and instance.  HOWEVER, one might hope
that if ever standard exception classes ARE changed in a way that is
not backwards compatible, by adding __eq__ &c, then at the same time
they might be made new-style classes, which would in any case have
much lesser potential for old-code breakage.


> You may want to bring this issue up on python-dev.

Good suggestion -- but I'd further suggest the class-vs-instance
and old-vs-new classes distinctions be clearly kept in mind when 
so doing.


Alex