What's the failed check? How has it come to that conclusion? I guess it's with conda=Yes.

Should I split the tests into individual functions? I certainly can, but that would decrease the readability of the code, making numerous functions, of which the def lines, the doc strings, and the spaces in between would make the most of the code. Anyway, it's up to you to decide.

What's the failed check? How has it come to that conclusion? I guess it's with conda=Yes.

Seems like the coveralls hook status is just misbehaving because the actual run its linked to confirms the status is still the same. Hopefully the next push should fix it.

Should I split the tests into individual functions? I certainly can, but that would decrease the readability of the code, making numerous functions, of which the def lines, the doc strings, and the spaces in between would make the most of the code. Anyway, it's up to you to decide.

As my review suggests, you can instead achieve the same using Pytest's paramertization, which is actually shorter than the existing test code.

In addition to parameterizing the tests, I also suggest doing an isinstance check that py_date has the expected Python type in each case.

I'm sorry I forgot to answer this. The point is that the type check is conducted internally in the __eq__ function. These are the fragments of datetime.py (identical for Python 3.7 and 3.11):

• in datetime.date:

    def __eq__(self, other):
        if isinstance(other, date):
            return self._cmp(other) == 0
        return NotImplemented

• in datetime.time:

    def __eq__(self, other):
        if isinstance(other, time):
            return self._cmp(other, allow_mixed=True) == 0
        else:
            return NotImplemented

• in datetime.datetime:

    def __eq__(self, other):
        if isinstance(other, datetime):
            return self._cmp(other, allow_mixed=True) == 0
        elif not isinstance(other, date):
            return NotImplemented
        else:
            return False

Ah, I see—technically, py_date's __eq__ (which gets called first being on the LHS, or if on the RHS would get called if the NotImplemented path is taken in the __eq__ above) could theoretically compare equal with a datetime, etc. without being one. But that's probably mostly hypothetical pedantry on my part.

being on the LHS

Oh, indeed. Thanks for the catch. I've added the explicit type checks. This should make the code more clear.

Thanks!