Should PEP 498 specify if rf'...' is valid?

It mentions fr'...' as a formatted raw string but doesn't say anything about rf'...'. Right now, in implementing PEP 498 support in Howl (https://github.com/howl-editor/howl/pull/118 and https://github.com/howl-editor/howl/commit/1e577da89efc1c1de780634b531f64346...), I assumed both were valid. Should the PEP be more specific? BTW, at the rate language-python is going, GitHub will get syntax highlighting for f-strings in 2050. :D -- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.

On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
Yes, I'll add some wording. Note that currently, there are 24 valid prefixes: ['B', 'BR', 'Br', 'F', 'FR', 'Fr', 'R', 'RB', 'RF', 'Rb', 'Rf', 'U', 'b', 'bR', 'br', 'f', 'fR', 'fr', 'r', 'rB', 'rF', 'rb', 'rf', 'u']
BTW, at the rate language-python is going, GitHub will get syntax highlighting for f-strings in 2050. :D
Heh. If we add binary f-strings, there are 80 permutations: ['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br', 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR', 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb', 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr', 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf', 'rf', 'rfB', 'rfb', 'u'] I think the upper/lower ones are nuts, but it's probably too late to do anything about it. 'FbR', really? Eric.

But it'd be weird now if fR worked but fbR didn't. On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze <srkunze@mail.de> wrote:
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/

On 22 October 2015 at 19:12, Eric V. Smith <eric@trueblade.com> wrote:
My own objection isn't to allowing "fR" or "fbR", it's to allowing the uppercase "F". I also don't understand why we can't say "if 'f' is part of a string prefix, it must be first". That would mean we kept the current 14 combinations: ['B', 'BR', 'Br', 'R', 'RB', 'Rb', 'U', 'b', 'bR', 'br', 'r', 'rB', 'rb', 'u'] And added only 13 more possibilities, being a lowercase 'f' prefix on its own, and as a prefix for the various b/r combinations: ['fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', 'frb'] I don't think it would ever be worth the compatibility break to require lowercase for 'rbu', or to enforce a particular relative order (although those could be good pylint rules, if they aren't already), but there's no such restrictions for the new 'f' prefix. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 10/23/2015 08:20 AM, Nick Coghlan wrote:
On 22 October 2015 at 19:12, Eric V. Smith wrote:
On 10/22/2015 1:09 PM, Ryan Gonzalez wrote:
But it'd be weird now if fR worked but fbR didn't.
Or bR (which is currently allowed) but not fbR in the future.
Sometimes order matters, and sometimes it does not. If the order does not have an impact on the final code, it does not matter, and making us have to remember an order that does not matter is a waste. -- ~Ethan~

On 26.10.2015 16:22, Ethan Furman wrote:
Order that matters? You must be kidding. That would turn different types of string extremely hard to understand because semantics differ. That is, btw., one reason, why I favor a fixed order (alphabetically or something). Easy to remember and no way to misinterpret it. Best, Sven

On 2015-10-26 18:45, Sven R. Kunze wrote:
In Python 2, how often have you seen prefix "ur" rather than "ru"? I always used "ur". How often is alphabetical order used in the prefixes? If the order isn't alphabetical, then it's going to be some order that's harder to remember, so I agree with Ethan here.

On 26 October 2015 at 19:43, MRAB <python@mrabarnett.plus.com> wrote:
In Python 2, ru". . ." is a SyntaxError, despite R coming before U in the alphabet. And rb". . ." is also a SyntaxError, but in Python 3 it was made legal. I don’t see much point restricting the order of rf". . ." versus fr". . .". Neither flag is particularly more important than the other, and even if one were, should that one be at the front, or at the end closer to the string?

On 26.10.2015 20:54, Ethan Furman wrote:
You misunderstand -- the order of string prefixes does *not* matter, so forcing us to use one is silly.
I don't think so. It's better to have less possibilities in the beginning. So later on, we can easily relax the restrictions without breaking compatibility. Best, Sven

On 27/10/2015 18:39, Sven R. Kunze wrote:
Please no. Having a memory much like a bottomless sieve I have no intention of reading the manual every time I need to use string prefixes. Would the table listing "string prefix precedence" in The Fine Docs™ be unique in the programming world? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Oct 27, 2015, at 4:39 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Plus, it's too late for this. What would the manual say: "either br or rb is okay, but you if you want fbr you can't spell it frb."? (Assuming we add binary f-strings.) Let's just leave it as any order, and with any capitalization. Eric.

Have you ever used a command line application that --accepted --Boolean --flags? Have you ever found one that required the flags to be in order? You remember how much you hated that application for being so arbitrary about the input? That is exactly how I feel about the order mattering for string prefixes in 2.7. 3.x got rid of that, and that is one of the few undeniably good choices made in python 3. for the love of all that is holy, don't un-fix that. On 10/27/2015 14:39, Sven R. Kunze wrote:

On 28 October 2015 at 20:05, Alexander Walters <tritium-list@sdamon.com> 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, and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime) 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"). It's only a mild preference, but the main benefit I see is reining in the combinatorial explosion of possible string prefixes before it even has a chance to start getting out of hand.
one of the few undeniably good choices made in python 3.
There's no need here for passive aggressive snark directed at the designers providing you with a free programming language. Folks have the entire internet to complain about how much they dislike our work (where we can pick and choose whose feedback we want to listen to), so we don't need to accept it here. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 10/31/2015 8:48 PM, Nick Coghlan wrote:
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.
It makes sense to me that f should be kept logically distinct from the other two.
-- Terry Jan Reedy

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:
-- --Guido van Rossum (python.org/~guido)

On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
Yes, I'll add some wording. Note that currently, there are 24 valid prefixes: ['B', 'BR', 'Br', 'F', 'FR', 'Fr', 'R', 'RB', 'RF', 'Rb', 'Rf', 'U', 'b', 'bR', 'br', 'f', 'fR', 'fr', 'r', 'rB', 'rF', 'rb', 'rf', 'u']
BTW, at the rate language-python is going, GitHub will get syntax highlighting for f-strings in 2050. :D
Heh. If we add binary f-strings, there are 80 permutations: ['B', 'BF', 'BFR', 'BFr', 'BR', 'BRF', 'BRf', 'Bf', 'BfR', 'Bfr', 'Br', 'BrF', 'Brf', 'F', 'FB', 'FBR', 'FBr', 'FR', 'FRB', 'FRb', 'Fb', 'FbR', 'Fbr', 'Fr', 'FrB', 'Frb', 'R', 'RB', 'RBF', 'RBf', 'RF', 'RFB', 'RFb', 'Rb', 'RbF', 'Rbf', 'Rf', 'RfB', 'Rfb', 'U', 'b', 'bF', 'bFR', 'bFr', 'bR', 'bRF', 'bRf', 'bf', 'bfR', 'bfr', 'br', 'brF', 'brf', 'f', 'fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', 'frb', 'r', 'rB', 'rBF', 'rBf', 'rF', 'rFB', 'rFb', 'rb', 'rbF', 'rbf', 'rf', 'rfB', 'rfb', 'u'] I think the upper/lower ones are nuts, but it's probably too late to do anything about it. 'FbR', really? Eric.

But it'd be weird now if fR worked but fbR didn't. On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze <srkunze@mail.de> wrote:
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/

On 22 October 2015 at 19:12, Eric V. Smith <eric@trueblade.com> wrote:
My own objection isn't to allowing "fR" or "fbR", it's to allowing the uppercase "F". I also don't understand why we can't say "if 'f' is part of a string prefix, it must be first". That would mean we kept the current 14 combinations: ['B', 'BR', 'Br', 'R', 'RB', 'Rb', 'U', 'b', 'bR', 'br', 'r', 'rB', 'rb', 'u'] And added only 13 more possibilities, being a lowercase 'f' prefix on its own, and as a prefix for the various b/r combinations: ['fB', 'fBR', 'fBr', 'fR', 'fRB', 'fRb', 'fb', 'fbR', 'fbr', 'fr', 'frB', 'frb'] I don't think it would ever be worth the compatibility break to require lowercase for 'rbu', or to enforce a particular relative order (although those could be good pylint rules, if they aren't already), but there's no such restrictions for the new 'f' prefix. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 10/23/2015 08:20 AM, Nick Coghlan wrote:
On 22 October 2015 at 19:12, Eric V. Smith wrote:
On 10/22/2015 1:09 PM, Ryan Gonzalez wrote:
But it'd be weird now if fR worked but fbR didn't.
Or bR (which is currently allowed) but not fbR in the future.
Sometimes order matters, and sometimes it does not. If the order does not have an impact on the final code, it does not matter, and making us have to remember an order that does not matter is a waste. -- ~Ethan~

On 26.10.2015 16:22, Ethan Furman wrote:
Order that matters? You must be kidding. That would turn different types of string extremely hard to understand because semantics differ. That is, btw., one reason, why I favor a fixed order (alphabetically or something). Easy to remember and no way to misinterpret it. Best, Sven

On 2015-10-26 18:45, Sven R. Kunze wrote:
In Python 2, how often have you seen prefix "ur" rather than "ru"? I always used "ur". How often is alphabetical order used in the prefixes? If the order isn't alphabetical, then it's going to be some order that's harder to remember, so I agree with Ethan here.

On 26 October 2015 at 19:43, MRAB <python@mrabarnett.plus.com> wrote:
In Python 2, ru". . ." is a SyntaxError, despite R coming before U in the alphabet. And rb". . ." is also a SyntaxError, but in Python 3 it was made legal. I don’t see much point restricting the order of rf". . ." versus fr". . .". Neither flag is particularly more important than the other, and even if one were, should that one be at the front, or at the end closer to the string?

On 26.10.2015 20:54, Ethan Furman wrote:
You misunderstand -- the order of string prefixes does *not* matter, so forcing us to use one is silly.
I don't think so. It's better to have less possibilities in the beginning. So later on, we can easily relax the restrictions without breaking compatibility. Best, Sven

On 27/10/2015 18:39, Sven R. Kunze wrote:
Please no. Having a memory much like a bottomless sieve I have no intention of reading the manual every time I need to use string prefixes. Would the table listing "string prefix precedence" in The Fine Docs™ be unique in the programming world? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence

On Oct 27, 2015, at 4:39 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Plus, it's too late for this. What would the manual say: "either br or rb is okay, but you if you want fbr you can't spell it frb."? (Assuming we add binary f-strings.) Let's just leave it as any order, and with any capitalization. Eric.

Have you ever used a command line application that --accepted --Boolean --flags? Have you ever found one that required the flags to be in order? You remember how much you hated that application for being so arbitrary about the input? That is exactly how I feel about the order mattering for string prefixes in 2.7. 3.x got rid of that, and that is one of the few undeniably good choices made in python 3. for the love of all that is holy, don't un-fix that. On 10/27/2015 14:39, Sven R. Kunze wrote:

On 28 October 2015 at 20:05, Alexander Walters <tritium-list@sdamon.com> 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, and only cause a compile time transformation in the stored constant without changing the code to load that constant at runtime) 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"). It's only a mild preference, but the main benefit I see is reining in the combinatorial explosion of possible string prefixes before it even has a chance to start getting out of hand.
one of the few undeniably good choices made in python 3.
There's no need here for passive aggressive snark directed at the designers providing you with a free programming language. Folks have the entire internet to complain about how much they dislike our work (where we can pick and choose whose feedback we want to listen to), so we don't need to accept it here. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 10/31/2015 8:48 PM, Nick Coghlan wrote:
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.
It makes sense to me that f should be kept logically distinct from the other two.
-- Terry Jan Reedy

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:
-- --Guido van Rossum (python.org/~guido)
participants (12)
-
Alexander Walters
-
Eric V. Smith
-
Ethan Furman
-
francismb
-
Guido van Rossum
-
Mark Lawrence
-
Martin Panter
-
MRAB
-
Nick Coghlan
-
Ryan Gonzalez
-
Sven R. Kunze
-
Terry Reedy