Confusing behaviour for sentinel constructed from string subclass

[Dutcho]

Bug report

Bug description:

Constructing a sentinel (new in 3.15 beta 1) from a str subclass works:

class MyStr(str):
    def __str__(self) -> str:
        return f'str {super().__str__()}'

    def __repr__(self) -> str:
        return f'repr {super().__repr__()}'


MISSING = sentinel(MyStr('MISSING'))

As per spec, the sentinel's name is the constructor's argument, i.e. MyStr:

print(type(MISSING.__name__), MISSING.__name__, repr(MISSING.__name__))
# <class '__main__.MyStr'> str MISSING repr 'MISSING'

However, the resulting sentinel's representation is confusing:

print(MISSING, [MISSING], {MISSING}, str(MISSING), repr(MISSING))
# MISSING [MISSING] {MISSING} str MISSING str MISSING

• straight output (MISSING) gives the __name__'s super(): MISSING
• same for embedded ([MISSING], {MISSING})
• but str() and repr() return MyStr __name__, which then becomes 'str MISSING' in both cases

I don't know whether using a MyStr subclass is out of sentinel's scope (the PEP doesn't exclude AFAIK, but if so, then I suggest it should reject at construction), or that the output (different for MISSING and MISSING.__name__) can even be considered a bug. But it sure confused me!

CPython versions tested on:

3.15

Operating systems tested on:

Windows

[johnslavik]

cc @JelleZijlstra

[JelleZijlstra]

This behavior isn't specific to sentinels, I think Python has some inconsistency in how to handle __str__/__repr__ methods that return a subclass of str.

You can see the same behavior with a custom class that returns an attribute value as its __str__:

class MyStr(str):
    def __str__(self) -> str:
        return f'str {super().__str__()}'

    def __repr__(self) -> str:
        return f'repr {super().__repr__()}'

class X:
    def __init__(self, attr):
        self.attr = attr
    def __str__(self): return self.attr
    def __repr__(self): return self.attr

x = X(MyStr("MISSING"))
print(str(x))  # str 'MISSING'
print(repr(x)) # str 'MISSING'
print([x]) # [MISSING]

The same behavior also appears if you use TypeVar(MyStr("MISSING"), infer_variance=True), which also directly returns its name in str/repr.

We could "fix" this by making sentinel's str/repr eagerly convert str subclasses into plain str, but I don't know if we should.

[Dutcho]

Didn't know this was more generic confusion. But as it is, 'fixing' just for sentinel would be suboptimal (i.e. special-casing).
Sorry for the red herring