11 ms·

I think you are right to prefer JS's backtick notation, but not in your reason. The main problem with python's f" syntax is that it's just a very complex, non-

by patrec 6y ago

I think you are right to prefer JS's backtick notation, but not in your reason. 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.

mixmastamyk 6y ago
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.
earthboundkid 6y ago
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.
- pansa2 6y ago
  > 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?
  - earthboundkid 6y ago
    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.
dragonwriter 6y ago
> 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).
- patrec 6y ago
  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.

by patrec 6y ago

mixmastamyk 6y ago

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.

earthboundkid 6y ago

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.

pansa2 6y ago
> 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?
- earthboundkid 6y ago
  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.

dragonwriter 6y ago

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

patrec 6y ago
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.