undefined | Better HN

0 pointsvorticalbox6y ago0 comments

they should pick f and put depreciation warnings on the other two, python is getting messy.

0 comments

5 comments · 1 top-level

uranusjr6y ago· 4 in thread

They can’t just deprecate the other two; f-string’s nature precludes it from being used in situations where formatting needs to occur lazily, e.g. i18n. This is the same reason why other languages with string interpolation also keep a format method around, e.g. Swift’s String(format:). I guess you could argue that they should at least deprecate %-formatting, and this has indeed been raised multiple times, even prior to f-string’s introduction, but the power of Backwards Compatibility Gods are still strong there, for better or for worse.

heavenlyblue6y ago

Nothing stops one from evaluating f-strings lazily. They could simply return a format string with parameters captured instead of interpolated string.

hjk056y ago

They could... but then they wouldn’t return the interpolated string, and they’d be just like using format, just saving the characters “.format” which ruins the exact thing people like about them.

wodenokoto6y ago

Can you elaborate on the exact thing people like about f-strings, because I honestly thought it was saving having to write `format`

heavenlyblue6y ago

Nah - you're clearly not using Python enough - the issue with current format is that of the identity of the arguments passed to it.

I need to do 2 changes every time I change a format string - I need to remove the symbol representing it's placement and then I need to remove the argument passed to .format.

Also old formatting does not easily support arbitrary expressions in the placements, thus in order to get those you need to change the arguments passed to the .format.

f-strings get rid of those issues altogether. What you're showing is whatever you have in the brackets - 0 indirection and thus less margin for (unnecessary) errors.

1 more reply

j / k navigate · click thread line to collapse