[nurpax]

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.

[quietbritishjim]

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

[mixmastamyk]

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.

[psalminen]

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

[dmurray]

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

[psalminen]

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

[nimih]

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'"

[ericvsmith]

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)

[ziml77]

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.

[wskinner]

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.

[dragonwriter]

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.

[foob]

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.