I've put together a proposal to have all strings be f-strings by default.

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.

> I've put together a proposal to have all strings be f-strings by default.

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?

> I've put together a proposal to have all strings be f-strings by default.

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 think that would be a pretty serious harm to Python as a language. When I was learning Python, I was using PHP, which has $ interpolation for double quoted strings but not single quotes. I didn’t understand how PHP worked at all and it really confused me. In retrospect, I don’t know why it was so hard to wrap my head around, but it was. Learning Python was liberating because I knew exactly when and how interpolation would take place. The decision not to follow the lead of Perl and Bash and auto-interpolate was made deliberately by Guido many years ago. It would be a shame to go back on that decision now.

Certainly this will lead to rather confused programmers.

F-strings certainly seem like opt-in behavior to me.

Won't happen. This would be a breaking change that would break pretty much every usage of `str.format`. Releasing a new incompatible version of a language is unlikely considering Python 2 to Python 3 migration mess.

I would personally be quite against that. That's a pretty large breaking change, with no clear benefit. It doesn't make the feature more discoverable, since you still need to know that using "{}" will cause interpolation. I'd say net zero effect on readability; mostly just individual preference. And potential negative impact on performance.

There would be a __future__ import to turn it on, at least for some number of releases. But yeah, I'm not sure it should ever be the default behavior. It makes most sense to me as a per-module opt-in, but then a __future__ import doesn't make sense. And we've resisted having per-module pragmas, so maybe it's dead in the water.

> And we've resisted having per-module pragmas, so maybe it's dead in the water.

There's a hack for that (no apologies for the self promotion; the project is a just funnin')

https://github.com/boothby/dissert

I agree it's not the most beautiful, but it was the best choice given the requirements. Basically, it had to be explicit, concise, use unused ASCII syntax, and not be too cryptic or incompatible. Other quote types or backticks were not available or an option.

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

It's consistent with other strings in Python like r-strings and the older u-strings.

And b-strings.

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.

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.

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.

> 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?

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.

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

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.

I quite like the idea of using double-quotes for format strings and single-quotes for normal strings.

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?

Yup, especially as you often need to access dict's with foo["field"] and you get a syntax error if the f-strings is also f"". JavaScript backtick syntax doesn't lead to this extra syntactic friction.

You can use any of

    f"{foo['field']}"
    f'{foo["field"]}'
    f"""{foo["field"]}"""

(I see from your carefully worded first sentence that you already knew this but still find it annoying, but I'll leave this here for any that aren't aware.)

Yes, and anyone who has written a "one-liner" at the command line is familiar with it. Wouldn't say it is a big problem.

The problem with this is when you run it through a formatter that changes all ' to ".

Sounds like a bug in your formatter, if it's meant to just do formatting but actually replaces valid syntax with invalid.

I don't totally disagree. My company uses the black formatter, which does this[0]. There are flags to skip string formatting, but is frowned upon at my organization.

[0] https://github.com/psf/black/blob/master/docs/the_black_code...

For what it's worth, black appears to do a reasonable thing and preserves the semantics of your quoted strings (as is promised by the documentation):

  $ echo "'foo'" | black -
  "foo"
  
  $ echo "'foo[\"bar\"]'" | black -
  'foo["bar"]'

  $ echo "'foo[\"bar\"]+\\'baz\\''" | black -
  "foo[\"bar\"]+'baz'"

This is because of how f-strings were initially implemented: I piggy-backed them off of "regular" strings, then post-parsed inside that string. But the restriction is that the entire f-string (after the f) needs to be a valid regular Python string.

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)

I'm surprised it works like that in Python. C# has similar interpolated strings but there it's legal to embed quotation marks within the curly brackets. Though I guess it's less necessary in Python since you can just use the other type of quote inside.

This is easily avoidable in python by using single quotes for the outer string and double quotes for the inner string, or vice versa. Or, use triple quotes for the outer string.

Yeah, if you get to the level of nesting where having available quotes is an issue, you really need to break it up into multiple expressions.

It can feel annoying sometimes, but it's also nice that it prevents you from getting overly complicated with your string interpolations. Human readability is highly valued in Python culture, and things start getting hard for humans to quickly parse when you allow arbitrarily complex interpolation expressions. Assigning your complicated expression to a well-named variable first will usually make your code more readable, even if it's slightly more verbose.