Re:Python 3's F-Strings: An Improved String Formatting Syntax
by mixmastamyk on Wednesday January 20, 2021 @04:08PM
(#25852019)
It's not a hack or broken. The formatting language existed before f-strings and is somewhat a separate issue.
I'm not sure I expect it to handle every Unicode nuance either, when there are modules in the stdlib for that.
Re:Python 3's F-Strings: An Improved String Formatting Syntax
by earthboundkid on Wednesday January 20, 2021 @10:39PM
(#25855088)
Yes. Python in general has gone from being “executable pseudo code” to a series of complex language design trade offs largely because it had failed to grasp the right abstractions in its evolution. Backtick functions in JS are so powerfully clever and basically impossible to recreate in Python.
Re:Python 3's F-Strings: An Improved String Formatting Syntax
by pansa2 on Wednesday January 20, 2021 @11:28PM
(#25855394)
> Python in general has gone from being “executable pseudo code” to a series of complex language design trade offs
Agree with this 100%.
> because it had failed to grasp the right abstractions in its evolution.
I'd be interested to know what you think the language's designers should have done differently?
Re:Python 3's F-Strings: An Improved String Formatting Syntax
by earthboundkid on Thursday January 21, 2021 @07:09AM
(#25858061)
Let’s go all the way back to `with`. What does it do? It encapsulates try/finally blocks and only try/finally. That is a weirdly specific thing to encapsulate. Why did they do that? Well, it turns out that making an anonymous block syntax that is compatible with Python’s grammar is hard, so you can’t have the equivalent of this JavaScript:
WithOpen(filename, f => {
// block
})
Because blocks aren’t viable, problems have to be solved on a case-by-case basis, which is hard to do well and leaves gaps.
Re:Python 3's F-Strings: An Improved String Formatting Syntax
by dragonwriter on Wednesday January 20, 2021 @10:49PM
(#25855161)
> Instead of this, f-strings have a lot of hardcoded and often broken behavior which can't be fixed let alone customized
They are customizable on an object-to-be-formatted basis (__format__ special method).
Re:Python 3's F-Strings: An Improved String Formatting Syntax
by patrec on Thursday January 21, 2021 @02:42AM
(#25856504)
Yes, you can work around some of the defects I mentioned by defining your own wrapper classe(s) and doing something like this:
f"Article: {fixformatting(somestr):20} Price: {fixformatting(price):5.3}"
Apart from somewhat negating the main advantage of f-strings (relative conciseness) it does not allow you take into account surrounding string context and of course will not fix problems when you have values that contain objects that already have __format__ defined. Also, python being python, you now slowed everything down by an order of magnitude.
The main problem with python's f" syntax is that it's just a very complex, non-extensible hack whereas in javascript you can prefix a tag to specify how the interpolation happens.
Instead of this, f-strings have a lot of hardcoded and often broken behavior which can't be fixed let alone customized. For example, you can specify a field width, but it will not even work properly even in a fixed-width context, because of quite common things like emojis or CJK or combining characters don't have their width computed correctly.