undefined | Better HN

0 pointsfny6y ago0 comments

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.

0 comments

sammorrowdrums6y 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.

n3k56y 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.

airstrike6y 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.

hermitdev6y 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.

j / k navigate · click thread line to collapse