@c-bata
Could you review this PR?

Thank you for your PR and sorry for the late response.
IntEnum's __str__ and __repr__ were changed in Python 3.11 (https://docs.python.org/3.13/library/enum.html#enum.IntEnum). So, we need to discuss what behavior is desirable.
I think using Enum.__str__ for __str__ and keeping __repr__ as default is appropriate (https://docs.python.org/3.13/library/enum.html#notes).

class TrialState(enum.IntEnum):
    ...
    __str__ = enum.Enum.__str__
    ...

>>> import optuna
>>> str(optuna.trial.TrialState.COMPLETE)
'TrialState.COMPLETE'
>>> repr(optuna.trial.TrialState.COMPLETE)
'<TrialState.COMPLETE: 1>'

It does not return a valid Python expression for __repr__, but I think what number is used as the value is important for developers (See the reference https://docs.python.org/3.13/reference/datamodel.html#object.__repr__).
What do you think?

I also prefer to use the default __repr__. When returning a valid Python expression isn't strictly required, let's use the default.

Thank you! Could you update this PR as my comment?

1. How about adding __str__ = enum.Enum.__str__? In the current implementation, str(optuna.trial.TrialState.COMPLETE) just shows '1'.
2. test_repr in test_frozen.py failed, but I think this test can be deleted.

strange, I pushed changes to the test but failing CI job seems to have executed the old test with eval...

Ah... sorry I misunderstood. I didn't notice there was another test using eval.

I just noticed the PR title was obsolete. Is the new title OK?

I think it's advisable to be there to notify people when stdlib changed behavior.

and also when the baseclass is changed again.

I think it’s advisable to be there to notify people when stdlib changed behavior.

If so, the test should compare with the full output of the repr like,

@pytest.mark.parametrize("state", TrialState)
def test_trial_state_repr(state: TrialState) -> None:
    assert f"<TrialState.{state.name}: {state.value}>" in repr(state)

but I think even this is not necessary, because Optuna does not depend on any __repr__ output as far as I know.

Would there be any issue if the base class of TrialState changed and its __repr__ output became different?

While I'm neutral about this test, Optuna's policy is to not test visual elements like visualization or error messages, so this test might be unnecessary.

I'd rather insist to keep the test because it describes the intention to use Enum.__repr__. Before I write this PR, I had totally no idea why TrialState.__repr__ is returning just a numeric string until finding this comment. PR comments are not easy to find.

I'm neutral with having tests, but aren't your points about documentation or comments in the code rather than about the tests themselves?

In the first place, why does TrialState use IntEnum?
IntEnum is intended for cases where the state needs to be interpreted as an integer—so that values can be added or subtracted.
However, TrialState is neither additive nor subtractive, so using a plain Enum would be more appropriate.

If Enum were used instead of IntEnum, the __repr__ method would not need to be overridden, and the corresponding test would be unnecessary.

To explain the background: TrialState was originally Enum, but was changed to IntEnum during the implementation of JournalStorage (#3854). Inheriting from int makes the JSON conversion implementation within JournalStorage simpler.

Of course documentation or comments will do. I won't insist to have the test if they are written but I prefer test personally because documentation or comments tend to get ignored.

Do you want me to write comments?

@ktns Thank you for your continuous contribution!
Sorry for the extra work, but due to the recent update in the branch protection rule after #6302, could you please merge the latest master branch into yours? 🙏

Regarding the ongoing discussion, I also think leaving a code comment instead of unit tests would be more appropriate in this case, since it would be difficult to find the background from the current test code. I don’t think we should spend too much time for a few lines of test code, but my impression is closer to @gen740’s and @not522’s opinions.

Sorry, I totallly forgot that I added a comment on __str__ definition. Does this look good?