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:
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?
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.
On 10/22/2015 7:32 AM, Eric V. Smith wrote:
On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
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?
Yes, I'll add some wording.
Now that I check, in the Specification section, the PEP already says "'f' may be combined with 'r', in either order, to produce raw f-string literals". So I think this case is covered, no? Eric.
Ah, I missed that part. Sorry! :/ On October 22, 2015 7:27:41 AM CDT, "Eric V. Smith" <eric@trueblade.com> wrote:
On 10/22/2015 7:32 AM, Eric V. Smith wrote:
On 10/21/2015 10:57 PM, Ryan Gonzalez wrote:
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?
Yes, I'll add some wording.
Now that I check, in the Specification section, the PEP already says "'f' may be combined with 'r', in either order, to produce raw f-string literals". So I think this case is covered, no?
Eric.
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On 22.10.2015 13:32, Eric V. Smith wrote:
['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?
Why not disallowing them? I for one could live with all-lower-case AND a predefined order. Best, Sven
On October 22, 2015 11:10:48 AM CDT, "Sven R. Kunze" <srkunze@mail.de> wrote:
On 22.10.2015 13:32, Eric V. Smith wrote:
['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?
Why not disallowing them?
I for one could live with all-lower-case AND a predefined order.
Well, now it's backwards-compatibility.
Best, Sven _______________________________________________ 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/rymg19%40gmail.com
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
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:
On 22.10.2015 18:17, Ryan Gonzalez wrote:
anything about it. 'FbR', really?
Why not disallowing them?
I for one could live with all-lower-case AND a predefined order.
Well, now it's backwards-compatibility.
Huh? There are no fb strings yet.
Best, Sven
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
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. Eric.
On Thu, Oct 22, 2015 at 12:02 PM, Sven R. Kunze <srkunze@mail.de <mailto:srkunze@mail.de>> wrote:
On 22.10.2015 18:17, Ryan Gonzalez wrote:
anything about it. 'FbR', really?
Why not disallowing them?
I for one could live with all-lower-case AND a predefined order.
Well, now it's backwards-compatibility.
Huh? There are no fb strings yet.
Best, Sven
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
_______________________________________________ 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/eric%2Ba-python-dev%40tru...
On 22 October 2015 at 19:12, Eric V. Smith <eric@trueblade.com> 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.
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.
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".
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:
On 10/23/2015 08:20 AM, Nick Coghlan 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".
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.
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:
On 26.10.2015 16:22, Ethan Furman wrote:
On 10/23/2015 08:20 AM, Nick Coghlan 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".
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.
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.
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:
On 2015-10-26 18:45, Sven R. Kunze wrote:
On 26.10.2015 16:22, Ethan Furman wrote:
On 10/23/2015 08:20 AM, Nick Coghlan 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".
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.
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.
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.
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 10/26/2015 11:45 AM, Sven R. Kunze wrote:
On 26.10.2015 16:22, Ethan Furman wrote:
On 10/23/2015 08:20 AM, Nick Coghlan 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".
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.
Order that matters? You must be kidding.
You misunderstand -- the order of string prefixes does *not* matter, so forcing us to use one is silly. -- ~Ethan~
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:
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
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:
On 27/10/2015 18:39, Sven R. Kunze wrote:
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
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?
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.
On 27.10.2015 22:19, Eric V. Smith wrote:
On Oct 27, 2015, at 4:39 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 27/10/2015 18:39, Sven R. Kunze wrote:
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 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? 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.
It was just for the protocol. The harm is already done. ;-) Best, Sven
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 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 _______________________________________________ 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/tritium-list%40sdamon.com
On 28 October 2015 at 20:05, Alexander Walters <tritium-list@sdamon.com> wrote:
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?
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:
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
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)
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.
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.
Well if the order is not important and all permutations are allowed then, at least those permutations can be used as an alphabet to build a hidden channel over it :-) Regards, francis
Yeah, that would be weird. Really? That's ridiculous. We don't allow DEF or DeF for function definitions either. So, I don't see any value in it. IMHO, It's time for a clean up again. On 22.10.2015 19:09, Ryan Gonzalez wrote:
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 <mailto:srkunze@mail.de>> wrote:
On 22.10.2015 18:17, Ryan Gonzalez wrote:
anything about it. 'FbR', really?
Why not disallowing them?
I for one could live with all-lower-case AND a predefined order.
Well, now it's backwards-compatibility.
Huh? There are no fb strings yet.
Best, Sven
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