If@ethanfurman prefers these to be verbatim code literals, as you've changed them to, instead of marked-up classes and attributes as they were before, then that's fine—it is a bit of a gray area.

However, in general when you're changing existing text, it seems to make more sense to at least initially propose the more minimal change that retains the previous markup, formatting and rendering, and just disables resolution (silencing the warnings):

I don't quite agree that these references should be:class: and:attr:, becauseColor is only defined in the docs. But, visual separation is a good enough argument to keep it this way.

Yeah, I think there's a good conceptual argument to be made for either way, and I don't have a particular preference myself—in fact, if anything generally I tend to prefer the style you used, for the reason you mentioned (plus its a little simpler).

However, I ended up mentioning it here because it preserved the existing syntax and styling as much as practical, and in particular because this particular usage is explicitly to highlight the semantic differences between the enum, members, and their names and values, which the markup helps accentuate (in fact, before I saw the next line, I hesitated to make this comment at all).

To note, though, due to a theme CSS bug, references in admonitions (like this note) are rendered with the background anyway—but will start working again as soon as that's fixed.

Same here; why not:

I have slightly modified your proposed change, because reading

:meth:`~object.__str__` is now :meth:`!int.__str__`

does not make much sense to me. Now it is:

:meth:`!__str__` is now :meth:`!int.__str__`

But the latteris essentially what readers will actually see, of course; the~ removes theobject prefix, so the original suggestion already displays as your second example, just with__str__ usefully cross-referenced to a description of the__str__ dunder and what it's used for, which seems to me to be potentially helpful to readers (and surely does no harm, at least).

I don't really get this either. This is a list of supported dunder and sunder names, and none of the other names have the class name explicitly prefixed, so I'm not sure why it makes sense to treat this differently.

Either__members__ should be explicitly documented underEnumType, like a number of other dunders and sunders are (including some listed here), and the link fixed here in the meantime (which displays the same as now until it is added):

or, if for whatever reason it doesn't make sense to explicitly document__members__ in the usual way, silence the warning without the prefix:

Let's document__member__ separately and keep the focus of this PRfocused 😉

Sure, but if__members__ should be documented (or the decision left until later), then deresolving it not only silences avalid warning, but also means that it will stay broken even if and when__members__ is documented, rather than start working automatically.

Therefore, unless@ethanfurman has some reason to not explicitly document__members__ but still list it here (which is possible), then the default approach should be the former, i.e. to fix it but leave it resolving, unless and until it is decided to explicitly leave it undocumented.