Why do I have to implement __hash__() for a Rust enum with derived Hash trait?

[pemistahl]

Hi, PyO3 is awesome but there is a little detail that I don't understand. I want to expose a Rust enum Foo to Python. Foo contains a method that returns all enum variants in a HashSet<Foo>. I want to make this method available to Python as well. The code looks something like this:

#[derive(Eq, PartialEq, Hash)]
#[pyclass]
enum Foo {
    First,
    Second,
    Third
}

#[pymethods]
impl Foo {
    #[classmethod]
    fn all(_cls: &PyType) -> HashSet<Self> {
        let mut hs = HashSet::new();
        hs.insert(Foo::First);
        hs.insert(Foo::Second);
        hs.insert(Foo::Third);
        hs
    }
}

This code compiles just fine. But when I try to run this method from Python, it fails:

>>> from my_module import Foo
>>> Foo.all()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
pyo3_runtime.PanicException: 
Failed to create Python set from HashSet: 
PyErr { type: <class 'TypeError'>, value: TypeError("unhashable type: 'builtins.Foo'"), traceback: None }

The solution I found was to override Python's __hash__ method:

#[pymethods]
impl Foo {
    fn __hash__(&self) -> u64 {
        let mut hasher = DefaultHasher::new();
        self.hash(&mut hasher);
        hasher.finish()
    }

    #[classmethod]
    fn all(_cls: &PyType) -> HashSet<Self> {
        let mut hs = HashSet::new();
        hs.insert(Foo::First);
        hs.insert(Foo::Second);
        hs.insert(Foo::Third);
        hs
    }
}

Now Foo.all() returns the set as expected. The documentation says the following:

By default, all #[pyclass] types have a default hash implementation from Python.

If this sentence is true, then why do I have to override __hash__() here to make it work, even though the Hash trait is already derived for Foo? Is this an exception that only affects enums? Is the documentation wrong or incomplete? Or is there maybe even a bug in PyO3?

[davidhewitt]

Oof, I'm pretty sure that this is caused because we generate a default implementation of ordering for you. As per the docs for __eq__ and friends:

Note that implementing any of these methods will cause Python not to generate a default __hash__ implementation, so consider also implementing __hash__.

So I'd consider this a bug. I'll create an issue now.

[pemistahl]

Alright, good to know, thank you. I hope it won't be too difficult for you to fix it.

[sheldonrong]

@davidhewitt know you are a busy guy, any plans for this to be fixed yet? Thanks.

[davidhewitt]

We have #4206 which will enable this (although opt-in).

[sheldonrong]

Noice, thanks, looking forward to the next version!