Not sure yet, but I think those fields in bool have to be None.
In my opinion, If that's not working with None, any inherited object of numbers can make similar problem.

It seems int operations are needed for bool in CPython.

>>> (True + True) ** True
2

Since PyBool is a subclass of PyInt and inherits its methods, so (True + True) ** True should somehow work without the above overriding in as_number I think.

I am sorry to make confusion. I agree bool need int operations.
But I'd like to say manually filling PyNumberMethods is not the way to do.
We can do that job only for builtin types written in Rust.
Making them None and finding a way to make it work will be helpful to solve the problem in general.

Did not test but I think PyBool is working with int number methods via mro search in PyNumber::find_methods().

But Maybe we can override it in PyBool to have some optimize

No, it wasn't. Because that is a static variable. We have no way to edit it later.

@qingshi163 do you have any suggestion?

I think we can inherit slots when initializing the subclass

https://github.com/python/cpython/blob/71db5dbcd714b2e1297c43538188dd69715feb9a/Objects/typeobject.c#L8849-L8902

slots will be inherit if subclass does not override it.

when there is a change of slots on the type, cpython recusively update slots for all the subclasses.

slots will be inherit if subclass does not override it.

It is true in cpython but not here yet. That's the reason we always call mro_find_map() to find slots.

Here is more room to optimize because and, xor, or actually doesn't require to increase reference count.
But it looks working fine.

To fully optimize it, PyBool::and can be changed like this and AsNumber can call inner_and

    #[pymethod(name = "__rand__")]
    #[pymethod(magic)]
    fn and(lhs: PyObjectRef, rhs: PyObjectRef, vm: &VirtualMachine) -> PyObjectRef {
        Self::inner_and(&lhs, &rhs, vm)
    }
    fn inner_and(lhs: &PyObject, rhs: &PyObject, vm: &VirtualMachine) -> PyObjectRef {
        if lhs.fast_isinstance(vm.ctx.types.bool_type)
            && rhs.fast_isinstance(vm.ctx.types.bool_type)
        {
            let lhs = get_value(&lhs);
            let rhs = get_value(&rhs);
            (lhs && rhs).to_pyobject(vm)
        } else {
            get_py_int(&lhs).and(rhs, vm).to_pyobject(vm)
        }
    }

This approach seems not working directly, since get_py_int(&lhs).and(rhs, vm) requires rhs to be an PyObjectRef as defined in int.rs.

maybe rhs.to_owned() fornow. we can optimize int.and also in same way later

I'm not sure but would rhs.to_owned() be an extra burden? If it's ok (for now), I will adopt the above practice.

Yes, rhs.to_owned() is extra cost, and still same as previous one. Adding TODO: or FIXME: can be helpful.
It is on the way to go to the right design.