Eh. I don't see the point of arguing about the order. String literals may have one or more character prefixes that modify the meaning. Some of those prefixes may be combined; others may not. Given that we allow combining the r and b prefixes in either order, and we allow combining r and f, I don't think we should be picky about the order in which those can appear. Saying that f must come first because it has a different kind of effect (call it "runtime") doesn't make sense to me.

On Sat, Oct 31, 2015 at 7:32 PM, Terry Reedy <tjreedy@udel.edu> wrote:

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
"magic_format_call_that_needs_compiler_assistance(<normal string
literal>)", 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

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

--Guido van Rossum (python.org/~guido)