Hacker News new | past | comments | ask | show | jobs | submit login

By itself I agree, every now and then you write a few lines that will be made a little shorter now that := exists.

But there's a long standing trend of adding more and more of these small features to what was quite a clean and small language. It's becoming more complicated, backwards compatibility suffers, the likelyhood your coworker uses some construct that you never use increases, there is more to know about Python.

Like f-strings, they are neat I guess. But we already had both % and .format(). Python is becoming messy.

I doubt this is worth that.




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


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.


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


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.


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


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.


I struggle to understand how what you talked about is relevant here. The problem parent talked about is how this laziness could be implemented without losing what makes f-string awesome right now. It’s not viable, which backs my reasoning why at least one alternative format method is required.

That said, I also struggle to understand how you’d claim parent clearly not using Python enough, when your description of str.format shows a lack of understanding to it yourself. One of the advantages of str.format over %-formatting is exactly that you do not need to modify the arguments passed to str.format when removing components from the source string:

    >>> '{0} {1} {2}'.format('a', 'b', 'c')
    'a b c'
    >>> '{0} {2}'.format('a', 'b', 'c')
    'a c'
Or preferably (using keyword arguments instead of positional):

    >>> '{x} {y} {z}'.format(x='a', y='b', z='c')
    'a b c'
    >>> '{x} {z}'.format(x='a', y='b', z='c')
    'a c'
But again, this doesn’t matter to parent’s argument. Nobody is arguing with you that f-string is better than alternatives for what it can do; we are trying to tell you that there are things it can’t do, and you did not get it.


>> One of the advantages of str.format over %-formatting is exactly that you do not need to modify the arguments passed to str.format when removing components from the source string:

It's not the string that most of the developers care about, it's the presence of the arguments to that string. The issue they are solving is "I would like to see A, B and C", rather than the issue of "I have provided A, B and C - would you please hide B from the view".

>> But again, this doesn’t matter to parent’s argument. Nobody is arguing with you that f-string is better than alternatives for what it can do; we are trying to tell you that there are things it can’t do, and you did not get it.

Please elaborate on what the f-string can't do? You have not provided the answer in your post. In my opinion, the only issue f-strings haven't solved is capturing the arguments in lambdas (before interplation) instead of their direct values. You, on the other hand - do not provide a clear explanation.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: