Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Steven D'Aprano
On Tue, Aug 30, 2016 at 11:02:25AM +, Philipp A. wrote: > Hi Eric, > > Very cool of you to get this going! > > I hope the outcome is to ban escapes within braced code parts of f-literals > for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n'] }baz' That looks like you are doing a

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Philipp A.
Hi Guido, thanks for calling me out. Yikes, I'm terribly sorry that it came over that way! I'll write the RFC. Should I expand the existing one (this would need Chris’ pending changes though) or write a new one? My goals were to sound factual and terse, not to insult anyone. And I don't see the

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Guido van Rossum
Philipp, you need to stop debating this issue *now*. You need to write a PEP that can go into Python 3.7. Further debate at the current level (a hair-width close to name-calling) is not going to sway anyone. (This actually goes for Chris too -- nothing is obviously going to change Philipp's

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Steven D'Aprano
On Tue, Aug 30, 2016 at 11:43:03PM +1000, Chris Angelico wrote: > On Tue, Aug 30, 2016 at 10:56 PM, Philipp A. wrote: > > My issue is just that it’s as much of a string as a call of a (string > > returning) function/method or an expression concatenating strings: > > > >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Guido van Rossum
Please just call it f-string and move on, we've had the naming debate previously, it's no longer productive. Regarding eventually supporting f'{'x'}', that will have to be a new PEP to extend PEP 498. (I previously thought it would be an incompatibility, but since f'{' is currently invalid, it's

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Philipp A.
Sorry, but I'm afraid you are projecting your thinking onto others. The syntactical constructs are called “string interpolations”, not “interpolated strings”. I.e. they're interpolations (a certain type of action) on strings. Strings are the objects, not the subjects. Strings are data, we have

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Chris Angelico
On Tue, Aug 30, 2016 at 10:56 PM, Philipp A. wrote: > My issue is just that it’s as much of a string as a call of a (string > returning) function/method or an expression concatenating strings: > > ''.join(things) # would you call this a string? > '{!r}'.format(x) # or

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Philipp A.
Hi Eric, Very cool of you to get this going! I hope the outcome is to ban escapes within braced code parts of f-literals for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n'] }baz' It really is how things work in every single language that i ever encountered that has template literals /

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Philipp A.
Eric V. Smith schrieb am Di., 30. Aug. 2016 um 14:13 Uhr: > There's debate on if that's the right way, and I personally think it's > probably not. Personally, I'd be happy with the only change being to not > allow backslashes inside braces. But that's not an argument that I'm

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Eric V. Smith
On 08/30/2016 07:02 AM, Philipp A. wrote: > Very cool of you to get this going! Thanks for raising the issue. > I hope the outcome is to ban escapes within braced code parts of > f-literals for 3.6 and add them “the right way” in 3.7: f'foo{ bar['\n'] > }baz' There's debate on if that's the

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-30 Thread Terry Reedy
On 8/29/2016 5:33 PM, Eric V. Smith wrote: On 8/29/2016 5:26 PM, Ethan Furman wrote: On 08/29/2016 02:16 PM, Eric V. Smith wrote: I've been looking at this, and I agree it's the best thing to do, for now (and possibly forever). I'm just not convinced I can get it done before alpha 1. Isn't

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Nick Coghlan
On 30 August 2016 at 07:40, Steve Dower wrote: > On 29Aug2016 1433, Eric V. Smith wrote: >> >> On 8/29/2016 5:26 PM, Ethan Furman wrote: >>> >>> Update the PEP, then it's a bugfix. ;) >> >> >> Heh. I guess that's true. But it's sort of a big change, so shipping >> beta 1

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Steve Dower
On 29Aug2016 1433, Eric V. Smith wrote: On 8/29/2016 5:26 PM, Ethan Furman wrote: Update the PEP, then it's a bugfix. ;) Heh. I guess that's true. But it's sort of a big change, so shipping beta 1 with the code not agreeing with the PEP rubs me the wrong way. Or, I could stop worrying and

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Eric V. Smith
On 8/29/2016 5:40 PM, Steve Dower wrote: On 29Aug2016 1433, Eric V. Smith wrote: On 8/29/2016 5:26 PM, Ethan Furman wrote: Update the PEP, then it's a bugfix. ;) Heh. I guess that's true. But it's sort of a big change, so shipping beta 1 with the code not agreeing with the PEP rubs me the

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Ethan Furman
On 08/29/2016 02:16 PM, Eric V. Smith wrote: I've been looking at this, and I agree it's the best thing to do, for now (and possibly forever). I'm just not convinced I can get it done before alpha 1. Isn't the f-string feature already in place? Update the PEP, then it's a bugfix. ;) --

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Eric V. Smith
Oops, I meant beta 1 where I said alpha 1. Eric. On 8/29/2016 5:12 PM, Eric V. Smith wrote: On 8/23/2016 8:18 AM, Nick Coghlan wrote: On 21 August 2016 at 03:32, Eric V. Smith wrote: If anything, I'd make it an error to have any backslashes inside the brackets of an

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-29 Thread Eric V. Smith
On 8/23/2016 8:18 AM, Nick Coghlan wrote: On 21 August 2016 at 03:32, Eric V. Smith wrote: If anything, I'd make it an error to have any backslashes inside the brackets of an f-string for 3.6. We could always remove this restriction at a later date. +1 for this if you can

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-23 Thread Nick Coghlan
On 21 August 2016 at 03:32, Eric V. Smith wrote: > If anything, I'd make it an error to have any backslashes inside the > brackets of an f-string for 3.6. We could always remove this restriction at > a later date. +1 for this if you can find a way to do it - it eliminates the

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-21 Thread Chris Angelico
On Sun, Aug 21, 2016 at 5:51 PM, Franklin? Lee wrote: > Speaking of which, how is this parsed? > f"{'\n'}" > If escape-handling is done first, the expression is a string literal holding > an actual newline character (normally illegal), rather than an escape

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Eric V. Smith
On 8/19/2016 2:57 PM, Guido van Rossum wrote: I don't think we should take action now. Would it make sense, as a precaution, to declare the PEP provisional for one release? Then we can develop a sense of whether the current approach causes real problems. We could also emit some kind of warning

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Paul Moore
On 20 August 2016 at 05:02, Random832 wrote: > On Fri, Aug 19, 2016, at 19:09, Paul Moore wrote: >> So, to me >> >> f'{x.partition(' + ')[0]}' >> >> reads as a string concatenation. I'm not sure how you'd expect a >> syntax highlighter to make it look like anything else,

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Paul Moore
On 20 August 2016 at 04:57, C Anthony Risinger wrote: > The two string parts are string-colored and the x.partition bits would look > like > any other code in the file. It won't look like concatenation at that point. That's entirely subjective and theoretical (unless you've

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Stephen J. Turnbull
C Anthony Risinger writes: > The only time I personally use a different quote is when it somehow > makes the data more amenable to the task at hand. The data! The > literal data! Not the expressions I'm conveniently inlining with > the help of f-strings. You do *not* know that yet! *Nobody*

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Brendan Barnwell
On 2016-08-19 20:57, C Anthony Risinger wrote: In a quality editor, everything about the {...} will tell me I'm writing a Python expression. It'll be colored like an expression. It'll do fancy completion like an expression. Aw shucks, it*IS* a Python expression! Except for one tiny detail: I'm

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-20 Thread Brendan Barnwell
On 2016-08-19 13:11, C Anthony Risinger wrote: It might be harder to find the end of an f-string in one shot, but I think that's the crux of the issue: to a reader/developer, is an f-string conceptually one thing or a compound thing? To me (someone who would like to see f-string expressions

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Ethan Furman
On 08/19/2016 08:57 PM, C Anthony Risinger wrote: [...] The appeal of f-strings is the rapid inlining of whatever plus string data. "Whatever" is typically more complex than a simple attribute access or variable reference, though not much more complex eg. `object.method(key, "default")`. If

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread C Anthony Risinger
On Fri, Aug 19, 2016 at 6:09 PM, Paul Moore wrote: > On 19 August 2016 at 21:50, C Anthony Risinger wrote: > > The only real point I'm trying to make is that expressions within an > > f-string are an *escape*. They escape the normal semantics of a string >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Paul Moore
On 19 August 2016 at 21:50, C Anthony Risinger wrote: > The only real point I'm trying to make is that expressions within an > f-string are an *escape*. They escape the normal semantics of a string > literal and instead do something else for a while. Therefore, the escaped >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread David Mertz
Ok. My .vimrc is probably different from yours. I'm sure you are right I *could* make that happen. But I haven't so far. On Aug 19, 2016 1:50 PM, "C Anthony Risinger" wrote: > On Fri, Aug 19, 2016 at 3:39 PM, David Mertz wrote: > >> I don't think I've ever

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread C Anthony Risinger
On Fri, Aug 19, 2016 at 3:11 PM, C Anthony Risinger wrote: > > > When I look at a string I want to immediately know just how literal it > really is. > To further this point, editors today show me \n and \t and friends in a different color, because they are escapes, and this

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Chris Angelico
On Sat, Aug 20, 2016 at 4:43 AM, Eric V. Smith wrote: > Maybe I'm the odd man out, but I really don't care if my editor ever syntax > highlights within f-strings. I don't plan on putting anything more > complicated than variable names in my f-strings, and I think PEP 8 should

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Guido van Rossum
I don't think we should take action now. Would it make sense, as a precaution, to declare the PEP provisional for one release? Then we can develop a sense of whether the current approach causes real problems. We could also emit some kind of warning if the expression part contains an escaped

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Eric V. Smith
On 8/18/2016 11:05 AM, Philipp A. wrote: Hi, I originially posted this via google groups, which didn’t make it through to the list proper, sorry! Read it here please: https://groups.google.com/forum/#!topic/python-ideas/V1U6DGL5J1s Hi, Philipp. I'm including your original proposal here, so

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Nick Coghlan
On 19 August 2016 at 18:27, Eric V. Smith wrote: > For something else that would become significantly more complicated to > implement, you need look no further than the stdlib's own tokenizer module. > So Python itself would require changes to parsers/lexers in Python/ast.c, >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread Eric V. Smith
On 8/19/2016 1:16 AM, Terry Reedy wrote: On 8/18/2016 8:27 PM, Eric V. Smith wrote: So something that parses or scans a Python file and currently understands u, b, and r to be string prefixes, just needs to add f to the prefixes it uses, and it can now at least understand f-strings (and

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-19 Thread אלעזר
בתאריך יום ו׳, 19 באוג' 2016, 08:29, מאת Terry Reedy ‏: > On 8/18/2016 8:18 PM, Steven D'Aprano wrote: > > On Fri, Aug 19, 2016 at 02:17:29AM +1000, Chris Angelico wrote: > > > >> Format codes are just text, > > > > I really think that is wrong. They're more like executable

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Steven D'Aprano
On Thu, Aug 18, 2016 at 08:27:50PM -0400, Eric V. Smith wrote: > Right. Because all strings (regardless of prefixes) are first parsed as > strings, and then have their prefix "operator" applied, it's easy for a > parser to ignore any sting prefix character. Is that why raw strings can't end

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Terry Reedy
On 8/18/2016 8:27 PM, Eric V. Smith wrote: On 8/18/2016 3:15 PM, Terry Reedy wrote: Without the escapes, existing f-unaware highlighters like IDLE's will be broken in that they will highlight the single f-string as two strings with differently highlighted content in the middle. For

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Terry Reedy
On 8/18/2016 3:30 PM, Steve Dower wrote: On 18Aug2016 1215, Terry Reedy wrote: On 8/18/2016 12:50 PM, Steve Dower wrote: I don't think f'{x.partition('-')[0]}' is any less readable as a result of the reused quotes, Why are you reusing the single quote', which needs the escaping that you

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Chris Angelico
On Fri, Aug 19, 2016 at 10:18 AM, Steven D'Aprano wrote: > On Fri, Aug 19, 2016 at 02:17:29AM +1000, Chris Angelico wrote: > >> Format codes are just text, > > I really think that is wrong. They're more like executable code. > >

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Eric V. Smith
On 8/18/2016 3:15 PM, Terry Reedy wrote: On 8/18/2016 12:50 PM, Steve Dower wrote: I find it hard to not read f'{x.partition(' + ')[0]}' as string concatenation. and it will certainly be easier for highlighters to handle (assuming they're doing anything more complicated than simply displaying

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Steven D'Aprano
On Thu, Aug 18, 2016 at 12:26:26PM -0400, Random832 wrote: > There's a precedent. "$()" works this way in bash - call it a recursive > parser context or whatever you like, but the point is that "$(command > "argument with spaces")" works fine, and humans don't seem to have any > trouble with it.

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Greg Ewing
Chris Angelico wrote: f"This is a number: {13:0\u07c4}" If I understand correctly, the proposal intends to make it easier for a syntax hightlighter to treat f"This is a number: {foo[42]:0\u07c4}" as f"This is a number: {foo[42] :0\u07c4}" ----

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Random832
On Thu, Aug 18, 2016, at 15:15, Terry Reedy wrote: > This is the crux of this thread. Is an f-string a single string that > contains magically handled code, or interleaved strings using { and } as > closing and opening quotes (which is backwards from their normal > function of being opener and

Re: [Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Random832
On Thu, Aug 18, 2016, at 12:17, Chris Angelico wrote: > The trouble with that way of thinking is that, to a human, the braces > contain something. They don't "uncontain" it. Those braced expressions > are still part of a string; they just have this bit of magic that gets > them evaluated. Consider

[Python-ideas] Let’s make escaping in f-literals impossible

2016-08-18 Thread Philipp A.
Hi, I originially posted this via google groups, which didn’t make it through to the list proper, sorry! Read it here please: https://groups.google.com/forum/#!topic/python-ideas/V1U6DGL5J1s My arguments are basically: 1. f-literals are semantically not strings, but expressions. 2. Their