aleax at aleax.it
Mon Sep 1 18:46:55 CEST 2003
> 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
More information about the Python-list