Normalize raw f-strings prefix

[jamesmyatt]

Is your feature request related to a problem? Please describe.

Black should normalize the prefix used for raw f-strings (https://www.python.org/dev/peps/pep-0498/#raw-f-strings). Both rf and fr work, but one should be preferred.

Currently, the following code is not changed:

    f = rf"hello {world}"
    f = fr"hello {world}"

Describe the solution you'd like

Pick one and normalize. I don't really care which. rf matches the name "raw f-string", but fr matches the example in PEP-498 and Jupyterlab syntax highlighting seems to prefer it.

Describe alternatives you've considered

Doing nothing leaves open the opportunity for inconsistency and disagreement.

Additional context

None

[JelleZijlstra]

Agree that we should standardize here. This also affects raw bytestrings: rb'x' and br'x' are both valid.

[cooperlees]

Just sharing that I also would like this.

I vote for alphabetical just for a simple standard. sort() would just do it then I feel.

fr"foo"
br"foo"

[ichard26]

Seconded. I weakly prefer rb"x" and fr"x" visually since they are recognizable pairs to me (rb is a Ruby file extension and fr is a code for French which I can speak some of). But going with the general standard and what tools prefer is definitely better.

edit: or some basic rule like Cooper's one above this comment works too

[ichard26]

@cooperlees you mean br? :D

>>> bf"foo"
  File "<stdin>", line 1
    bf"foo"
      ^
SyntaxError: invalid syntax
>>> 

edit and off-topic: I just realized I can edit anyone's comment now, I guess I could've done that instead lol

[cooperlees]

@cooperlees you mean br? :D

>>> bf"foo"
  File "<stdin>", line 1
    bf"foo"
      ^
SyntaxError: invalid syntax
>>> 

Sure ...

[felix-hilden]

While having a simple rule is elegant, I think matching spoken word is important like James pointed out. Just to provide one more perspective, I'd prefer:

• rf - raw f-string
• rb - raw byte string

The simple rule in this case would be "have r first", if simplicity is important.

[jamesmyatt]

I don't think the alphabetical order convention is a good one, otherwise you might end up with inconsistent placing e.g. br, fr and rx (under the hypothetical scenario where x and rx are a valid prefixes). I'd prefer either "r-first"---as in "raw f-string/byte string"---or "r-last"---as in the "f" or "b" are the most important parts of the prefix or possibly chain-rule i.e. the "raw" processing is applied before the "format" processing; I don't know how the parser actually handles it.

To me, "r-first"---as in "raw f-string/byte string"---is the clearest justification.

[Zac-HD]

Sorting will also have problems with the capital-R prefix, Rf"", Rb"", br"", fr"". I'd prefer "r-last" (fR"", bR"") but would be happy with any simple and consistent rule.

[jamesmyatt]

@Zac-HD I didn't know about the R-strings. Thanks for that 👍. Seems odd to have the more common syntax (i.e. lower case r) be for the special case of regular expressions, especially when br"" doesn't make sense ... I think, but I digress.

I think I agree that fR"" looks better than Rf"". In fact, I'm also moving towards the view that the "best" justification is "r-last" since it is less important than the "f" or "b", even if this isn't as "clear" as "r-first" as in "raw f-string".

[felix-hilden]

To find some common ground first, I think it would be reasonable to propose that no matter which "r/R", the order stays the same. Meaning no mixing rf with fR and vice versa. And I think allowing other capital letters is a no-go as well. So it seems that the suggestions have converged to:

• r first, as in spoken word: rb"str", rf"str", Rb"str", Rf"str"
• r last, as the common attribute applicable to both b and f: br"str", fr"str", bR"str", fR"str"

Personally I still feel like matching spoken word is more important, and I'm not bothered by the capital "R" being first. That being said arguments can be made both ways. Would the maintainers like to decide, or would we vote, or have a PR race? 😄

[JelleZijlstra]

We just need to make the call, one way or the other. Maybe ask for more opinions on Discord and then take a majority vote among the maintainers.