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

Reply via email to