[Python-Dev] Should PEP 498 specify if rf'...' is valid? (original) (raw)
Guido van Rossum guido at python.org
Sat Oct 31 23:46:27 EDT 2015
- Previous message (by thread): [Python-Dev] Should PEP 498 specify if rf'...' is valid?
- Next message (by thread): [Python-Dev] Should PEP 498 specify if rf'...' is valid?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 at 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 "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
Python-Dev mailing list Python-Dev at 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20151031/bca0e47e/attachment.html>
- Previous message (by thread): [Python-Dev] Should PEP 498 specify if rf'...' is valid?
- Next message (by thread): [Python-Dev] Should PEP 498 specify if rf'...' is valid?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]