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 <tjre...@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)
_______________________________________________ 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/archive%40mail-archive.com