I can't say I like the f" syntax much. I think JS's backtick is better.
Other than that, I agree, much better than % and less verbose than .format.
It's just the f" or f' that doesn't sit right with me
Other than that, I agree, much better than % and less verbose than .format.
It's just the f" or f' that doesn't sit right with me
Then you could drop the "f" prefix. I also propose adding a "p" prefix (for "plain") to remove the f-string parsing behavior.
I talked about it at the last Python core sprint, and it only got lukewarm support, so I'm not sure I'm going to pursue it.
There's a hack for that (no apologies for the self promotion; the project is a just funnin')
F-strings certainly seem like opt-in behavior to me.
Please, no.
I mean, it would be a breaking change, which needs a really compelling case, will make all introductory material wrong, and...offers what benefit?
Please don't do that. Seriously.
There is this trend in the Python community of blurring the line between a plain string and a formatting operation on that string, but there is a fundamental difference between the two. Instead of trying to ignore that difference, the language should make the difference explicit. "Explicit is better than implicit" is one of the things I like so much about Python. Please don't throw that away.
There is and should be a clear and fundamental difference between a plain string and a string formatting operation. The plain string is clearly the more fundamental of the two, so it should be the default.
And then there's the whole issue of breaking code with such a change.
Again, please don't do it. Don't change the language in such a fundamental way.
(I spent a lot of time thinking about it, and put the idea forward on python-ideas. Though string interpolation is nothing new of course.)
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.
I'm not sure I expect it to handle every Unicode nuance either, when there are modules in the stdlib for that.
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?
WithOpen(filename, f => {
// block
})
They are customizable on an object-to-be-formatted basis (__format__ special method).
f"Article: {fixformatting(somestr):20} Price: {fixformatting(price):5.3}"
This isn’t sufficient on its own, though - what about raw strings? Perhaps use “” for format strings, ‘’ for raw strings and get rid of normal strings altogether?
f"{foo['field']}"
f'{foo["field"]}'
f"""{foo["field"]}"""
[0] https://github.com/psf/black/blob/master/docs/the_black_code...
$ echo "'foo'" | black -
"foo"
$ echo "'foo[\"bar\"]'" | black -
'foo["bar"]'
$ echo "'foo[\"bar\"]+\\'baz\\''" | black -
"foo[\"bar\"]+'baz'"Since this:
"this is a "regular" string"
isn't valid, then neither is this:
f"dict lookup: {d["key"]}"
However, we've talked about changing f-string parsing from a "post-process regular strings" mode, to instead having the tokenizer and parser themselves aware of f-strings. When we do that, the f-string example above will work.
(edit for formatting)