4 ms·

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially bette

by fny 7y ago

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially better than f"now={str(now)}"? Ergonomically, I see little benefit for the added complexity.

airstrike 7y ago
Readability counts, though I agree Explicit is better than implicit. Special cases aren't special enough to break the rules, Although practicality beats purity.
hermitdev 7y ago
I agree that the simple examples don't show much benefit, but imagine if you had a really complex expression. I can see the value there.
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 ago
  In 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.

4 ms·

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially bette

by fny 7y ago

airstrike 7y ago
Readability counts, though I agree Explicit is better than implicit. Special cases aren't special enough to break the rules, Although practicality beats purity.
hermitdev 7y ago
I agree that the simple examples don't show much benefit, but imagine if you had a really complex expression. I can see the value there.
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 ago
  In 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.