[Python-Dev] Should PEP 498 specify if rf'...' is valid? (original) (raw)

Terry Reedy tjreedy at udel.edu
Sat Oct 31 22:32:38 EDT 2015

On 10/31/2015 8:48 PM, Nick Coghlan wrote:

Given that "f" is standing for a runtime transformation (unlike the purely declarative "b" and "r"), it makes sense to me to mentally translate it as "magicformatcallthatneedscompilerassistance()", so requiring the "f" to be first isn't arbitrary, it's slotting in where the function name would be for a call to a builtin.

I'd also like to leave the door open to i-strings in the future, so my answer to Eric's "What would the docs say?" question is that string prefixes can contain imperative runtime flags (which appear first, are mutually exclusive, are always lowercase, and cause a runtime transformation by changing the actual code generated at compile time) and declarative compile time flags (which can appear in any order after the imperative flag, may be in upper or lower case,

I think either order for b|u versus r is ok, even though a nuisance to specify in a grammer that assumes order significance. But given that Python is case-sensitive, I think the exception here was a mistake that need not be copied.

and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime)

It makes sense to me that f should be kept logically distinct from the other two.

Currently the only imperative prefix we have is "f", while "b", "u", and "r" are available as declarative prefixes. "i" has been proposed as a second imperative prefix, but is currently deferred until 3.7 at the earliest (after we have a release worth's of experience with "f").

-- Terry Jan Reedy

More information about the Python-Dev mailing list