I’m curious what sort of use-cases you have, and why using str is better than repr.
(Note that for the common case of stringifying ints or floats, it makes no difference which you use, but for the case of strings and other objects, it makes a big difference.)
I grepped my code, which I completely acknowledge is not representative of all Python code (everyone’s individual code is idiosyncratic). I found
-
three classes with a repr that calls
", ".join(repr(obj) for obj in self)or equivalent; -
two that use
strin place of repr; -
two examples of
sep.join(str(x) for x in something)outside of a__repr__; -
and one example of
sep.join(stringify(x) for x in something), for some custom stringify function.
Even at face value, that suggests that for my code, out of eight “stringify and join” operations, only half use str and the others use something else.
But we shouldn’t take this at face value.
With regard to the second item, I now realise that both of those __repr__ methods are wrong and need to be fixed by changing the call to str to use repr. I had failed to test or even look at the output of the method when the objects contained values other than ints and floats. E.g. Decimals or Fractions.
So in my code base, using a quick and dirty grep, I would say that 5 out of 8 examples of the pattern “stringify and join” use repr to do the stringification, 1 uses a custom function, and 2 use str (and I didn’t look too closely at those so that could easily change in the future too).
Well sure everybody writing code should know what they are doing, but I don’t see why you single out repr dunders here, or why you think repr dunders could not, or should not, take advantage of a built-in “stringify and join” function and method.
That’s not a use-case that’s a target audience, and for casual users, it is all the more important that the default choice of stringifier gets it right.
Also I wonder what the OP @jsbueno thinks about being lumped into “casual users” 