What if we make the hash from .args and .__dict__? That would cover most cases. For me it makes sense because they look like containers. There might be cases where a user doesn't want __eq__ or __hash__ for exception instances - how about we enable those methods just for the builtin types? And then the user can explicitly enable them for custom exceptions (there could be a special base ComparableException class that he could inherit from). Thanks, -- Ionel Cristian Mărieș, blog.ionelmc.ro On Wed, Feb 25, 2015 at 1:55 AM, Guido van Rossum <guido@python.org> wrote:
Actually, they don't have a __hash__ either -- they just inherit the default __hash__ from object, just as they inherit __eq__ from object (and both just use the address of the object). I can see many concerns with trying to define __eq__ for exceptions in general -- often there are a variety of fields, not all of which perhaps should be considered when comparing, and then there are user-defined exceptions which may have other attributes. I don't know what your use case was, but if, as you say, the exceptions you care about already have `args` attributes, maybe you should just compare that (and the type).
On Tue, Feb 24, 2015 at 3:43 PM, Ionel Cristian Mărieș <contact@ionelmc.ro
wrote:
Hey everyone,
I was writing a test the other day and I wanted to assert that some function raises some exception, but with some exact value. Turns out you cannot compare OSError("foobar") to OSError("foobar") as it doesn't have any __eq__. (it's the same for all exceptions?)
I think exceptions are great candidates to have an __eq__ method - they already have a __hash__ (that's computed from the contained values) and they are already containers in a way (they all have the `args` attribute).
Comparing exceptions in a test assertion seems like a good usecase for this.
Thanks, -- Ionel Cristian Mărieș, blog.ionelmc.ro
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)