On Tue, Aug 30, 2016 at 10:30 AM, Steven D'Aprano wrote:
[...]
> That looks like you are doing a key lookup on bar:
>
> bar = {'\n': 'something'}
> f'foo{ bar['\n'] }baz'
>
> looks like it will return 'foosomethingbaz'. I expect that syntax will
> confuse an awful lot of people.
Can we please sto
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 key
You need to write a new PEP. And it's PEP, not RFC.
On Tue, Aug 30, 2016 at 9:56 AM, Philipp A. wrote:
> 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 change
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
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 mind,
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:
> >
> > ''.join(things) # would y
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 n
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
co
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 this? it’s basically the s
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 /
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
> willing to get int
> On Tue, Aug 30, 2016 at 3:13 PM Eric V. Smith wrote:
> >On 08/30/2016 07:02 AM, Philipp A. wrote:
> > Also the name “f-strings” is really misleading: They’re composite
> > expressions that evaluate to strings. They can only be considered
> > strings if you have no braced code parts in them. So I
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 righ
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
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 with the code not agreein
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 ty
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 wr
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 the f-string feature already in place?
Yes
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. ;)
--
~Et
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 f-string for 3.6. We coul
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 find a way to do it
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
problematic cases wh
Sorry for replying to late, i had an email issue.
First two important things: 1. mental model and intuition and 2.
precendence.
About how to think of them: I’m strongly of the opinion that the mental
models of either an alternating sequence of strings and formatted
expressions, or a string with
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
> sequence which resolves to a n
On Aug 20, 2016 1:32 PM, "Eric V. Smith" wrote:
>
> 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 approac
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
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, to be honest
>
> One poss
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 implemented
it and re
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*
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 n
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 appe
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 I
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, to be honest
One possible syntax highlighting scheme:
- f' and ' are hilighte
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
> > literal and instead do something else
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
> sections should not lo
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 used a syntax highlighter than changed
On Fri, Aug 19, 2016 at 3:39 PM, David Mertz wrote:
> I don't think I've ever used a syntax highlighter than changed color of \n
> in a string. I get the concept, but I haven't suffered for the absence of
> that.
>
> Moreover, although I haven't yet used them, I really doubt I want extra
> syntax
I don't think I've ever used a syntax highlighter than changed color of \n
in a string. I get the concept, but I haven't suffered for the absence of
that.
Moreover, although I haven't yet used them, I really doubt I want extra
syntax highlighting in f-strings beyond simply the color strings appear
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 visually tells me the
On Fri, Aug 19, 2016 at 1:43 PM, Eric V. Smith wrote:
>
>
> With your proposal, it's much more difficult to find the end of an
> f-string. I do not think this is a reasonable requirement.
>
> For example, consider the following:
> f'a{func({'a{':1,'3}':[{}, ')', '{']})}b'
>
> A regex will not be a
On 19 August 2016 at 19:43, 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
> recommend something simi
On 19Aug2016 1157, 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 if
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
> recommend something
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 quote
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 tha
On 8/19/2016 2:07 AM, אלעזר wrote:
בתאריך יום ו׳, 19 באוג' 2016, 08:29, מאת Terry Reedy
mailto:tjre...@udel.edu>>:
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 real
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,
> IDLE, and Lib/tokeni
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
fr-strin
On 19 August 2016 at 06:07, Terry Reedy wrote:
> It seems to me that that this is at least somewhat a strawman issue.
>
> If you want to prohibit backslashed quote reuse in expressions, as in
> f'{x.partition(\'-\')[0]}', that is okay with me, as this is unnecessary*
> and arguably bad. The third
On 19.08.16 08:07, Terry Reedy wrote:
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',
בתאריך יום ו׳, 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 code.
> >
> > https://w
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 wit
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 code.
https://www.python.org/dev/peps/pep-0498/#expression-evaluation
I agree with you here.
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
f'{x.parti
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
don'
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.
>
> https://www.python.org/dev/peps/pep-0498/#expression-evaluation
>
> "
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 t
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.
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.
https://www.python.org/dev/peps/pep-0498/#expression-evaluation
"Just text" implies it is data:
result = "function(arg)"
like the
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}"
----
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,
I find it hard to not read f'{x.partition(' + ')[0]}' as string
concatenation.
That's a fair counter-example. Though f
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
On 8/18/2016 12:50 PM, Steve Dower wrote:
> I'm generally inclined to agree, especially as someone who is very
> likely to be implementing syntax highlighting and completion support
> within f-literals.
I consider these separate issues. IDLE currently provides filename
completion support within
On Thu, 18 Aug 2016 at 08:32 Philipp A. wrote:
> [SNIP]
> Brett Cannon schrieb am Mi., 17. Aug. 2016 um
> 20:28 Uhr:
>
>> They are still strings, there is just post-processing on the string
>> itself to do the interpolation.
>>
>
> Sounds hacky to me. I’d rather see a proper parser for them, whi
On 18Aug2016 0950, Steve Dower wrote:
I'm generally inclined to agree, especially as someone who is very
likely to be implementing syntax highlighting and completion support
within f-literals.
I also really don't like the subject line. "Do not require string
escapes within expressions in f-lit
I'm generally inclined to agree, especially as someone who is very
likely to be implementing syntax highlighting and completion support
within f-literals.
I stepped out of the original discussion near the start as it looked
like we were going to end up with interleaved strings and normal
expr
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
On Fri, Aug 19, 2016 at 1:05 AM, Philipp A. wrote:
> the embedded expressions are just normal python. the embedded strings just
> normal strings. you can simply switch between both using <{> and
> <[format]}>.
>
The trouble with that way of thinking is that, to a human, the braces
contain somethi
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 es
69 matches
Mail list logo
