Disable __str__ by raising an exception

[energizah]

In Python, repr is used for helpful debugging output for the developer, and str is used for the end user. Because object.__str__ defaults to behaving like object.__repr__, the two representations can get somewhat mixed, sometimes by accident. Often this problem manifests by accidentally writing some object's repr into a file after calling str() on it. I'm increasingly feeling that these are two different representations, and they should not be used interchangeably. Instead, most objects should not have __str__ at all, and that builtins.object.__str__ defaulting to behave like the repr is usually not what I want. To avoid this accidental mixing, I've taken to writing my own method:

def __str__(self):
    raise NotImplementedError(
f'object of type {type(self).__name__} has no str(). '
'Use `repr(obj)` instead.'
)

How would you feel about providing an option for this kind of method?

I'm filing this separately from #212 because it's a more specific idea for a particular implementation of __str__, rather than a framework for user-provided implementations.

[wsanchez]

This strikes me as a feature better suited to an extension than something that belongs in attrs proper, and that #212 or a wrapper around the class decorator could provide a means to implement that.

[hynek]

Yeah, it seem very specialized to me. We could talk a out what makes it hard/impossible to implement something yourself?

[energizah]

It's no problem to implement my own decorator; that's what I usually do. If @attr.s(str=raise_for_str) is to your taste, that would work for me.

FWIW, my view is that object.__str__ has the wrong default behavior: mixing repr and str is like Python 2 mixing bytes and unicode. And that rather than being a specific use case, this behavior should be fixed for as many people as possible, such as in attrs or in Python itself. If I apply my decorator to my own class, 1) only I get the bug-catching benefits, nobody else does, and 2) I get the bug-catching benefits on classes that only I wrote, not anybody else's.

[hynek]

I don't disagree, but I think it depends on your use-case. I only get to see str in Exceptions (where we had to add explicit str support in attrs. :|)

Well, creator-customization is coming…eventually. :)