4 ms·
It really feels like it's very explicit at this point that you want to cast whatever value interpolated into your format string to a string... I don't want a t
by sammorrowdrums 7y ago
It really feels like it's very explicit at this point that you want to cast whatever value interpolated into your format string to a string...
I don't want a type error for the most clear use case, in the same way I don't want one for print, because if I wanted a behaviour other than the basic string representation then I would still need to call something differently anyway.
Given that explicit control of the __str__ method is also baked into the language it's also very clear what to expect.
I like type errors when handling something like '1' + 1 because the JavaScript alternative is surprising and hides bugs. No surprises that a string formatter would coerce to string for me automatically (although I get that's maybe just personal feeling).
I love the f strings, they have made my codebase cleaner and clearer. Definitely a pythonic win.
- n3k5 7y agoIn GP's example, the call to str() isn't there to make sure you get a string instead of causing a type error; it's there to substitute str() for repr() (which also returns a string). Considering that this feature is mainly meant to make 'print debugging' more convenient, it makes sense that repr() is the default choice.