Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

And thanks for making it a reality. ;) -Mike On 09/08/2015 05:37 PM, Eric V. Smith wrote: ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/pytho

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

Yeah, can't wait to use it! -Mike On 09/08/2015 05:37 PM, Eric V. Smith wrote: On 9/8/2015 8:27 PM, Guido van Rossum wrote: I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who contributed. A lot of thought and discussion went into this -- Eric himself was against the idea

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/8/2015 8:27 PM, Guido van Rossum wrote: > I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who > contributed. A lot of thought and discussion went into this -- Eric > himself was against the idea when it first came up! Thanks, Guido. In the next few days I'll update the imp

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who contributed. A lot of thought and discussion went into this -- Eric himself was against the idea when it first came up! For those wondering about the fate of PEPs 501 and 502: 501 will be deferred, and 502 will be turned into

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Tue, 8 Sep 2015 at 10:26 Erik wrote: > Hi. > > I realise I'm coming late to the party on this, but I have a question > about something I don't think the PEP makes clear. > > > > When is the bytecode for the embedded expressions created? > > > Is it when the source code is parsed, or at runti

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

The byte code for the embedded expressions is all produced during the regular byte code generation phase. On Tue, Sep 8, 2015 at 3:30 AM, Erik wrote: > Hi. > > I realise I'm coming late to the party on this, but I have a question > about something I don't think the PEP makes clear. > > > > When

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

Hi. I realise I'm coming late to the party on this, but I have a question about something I don't think the PEP makes clear. When is the bytecode for the embedded expressions created? Is it when the source code is parsed, or at runtime when the f-string is evaluated? If the latter, the

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 05.09.2015 12:58, Chris Angelico wrote: On Sat, Sep 5, 2015 at 8:57 PM, Chris Angelico wrote: IMHO the main advantage of allowing expressions inside f-string is that it adds something really new compared to the current str.format() method. Without it, f-string are less interesting. I agree

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 04, 2015, at 08:01 PM, Guido van Rossum wrote: >And I'm ready to accept it. As I've mentioned to Eric, I think it's a great PEP, so congratulations on getting one through The Gauntlet. I know that in my own code, I'm looking forward to using it in however many years it takes for 3.6 to be

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 7:12 PM, Nathaniel Smith wrote: > On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith wrote: >> On 9/5/2015 3:23 PM, Nathaniel Smith wrote: >>> On Sep 5, 2015 11:32 AM, "Eric V. Smith" >> > wrote: Ignore the part about non-doubled '}'. The actual description i

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 1:00 PM, Eric V. Smith wrote: > On 9/5/2015 3:23 PM, Nathaniel Smith wrote: >> On Sep 5, 2015 11:32 AM, "Eric V. Smith" > > wrote: >>> Ignore the part about non-doubled '}'. The actual description is: >>> >>> To find the end of an expression, it lo

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 2:22 PM, Victor Stinner wrote: > > If you really want to allow *any* Python inside a f-string, can you >>> please at least explain in the PEP why you consider that it's a good >>> thing? >>> >> >> Sigh. We've gone over this on python-ideas. Your objection is not new. >> > >

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

> If you really want to allow *any* Python inside a f-string, can you >> please at least explain in the PEP why you consider that it's a good >> thing? >> > > Sigh. We've gone over this on python-ideas. Your objection is not new. > I'm sure that later others will have exactly the same question tha

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 12:18 PM, Guido van Rossum wrote: > On Sat, Sep 5, 2015 at 2:10 AM, haypo s > wrote: > > (is it possible to indent and comment code inside a f-string?) > > > Now that's an interesting question. I think the answer must be No, > because we don't wan

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 3:23 PM, Nathaniel Smith wrote: > On Sep 5, 2015 11:32 AM, "Eric V. Smith" > wrote: >> Ignore the part about non-doubled '}'. The actual description is: >> >> To find the end of an expression, it looks for a '!', ':', or '}', not >> inside of a string or (),

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 5, 2015 11:32 AM, "Eric V. Smith" wrote: > > > Actually, my current implementation doesn't use the lexer, although I > > suppose it could. I'm currently manually scanning the string, keeping > > track of strings and parens. To find the end of an expression, it looks > > for a '!', ':', or n

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

> Actually, my current implementation doesn't use the lexer, although I > suppose it could. I'm currently manually scanning the string, keeping > track of strings and parens. To find the end of an expression, it looks > for a '!', ':', or non-doubled '}', not inside of a string or (), [], or > {}.

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:14 PM, Gustavo Carneiro wrote: > Why not allow string concatenation without plus sign only if/when the > implementation becomes optimised to allow compile time concatenation? > This makes it crystal clear whether the concatenation is compile time or > runtime. If we allow it now, it'

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 12:18 PM, Guido van Rossum wrote: On Sat, Sep 5, 2015 at 2:10 AM, haypo s mailto:victor.stin...@gmail.com>> wrote: We already went over this. You might as well argue that __import__ or lambda should not be used as arguments to print(). It's an expression, and it must allow exactly

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 9/5/2015 1:28 PM, Nathaniel Smith wrote: > On Sep 5, 2015 9:20 AM, "Guido van Rossum" > wrote: >> >> The processing of f-strings described by the PEP uses several phases: >> >> - find the end of the string (the final quote[s]) using the same > algorithm used for all str

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 5, 2015 9:20 AM, "Guido van Rossum" wrote: > > The processing of f-strings described by the PEP uses several phases: > > - find the end of the string (the final quote[s]) using the same algorithm used for all string literals > - expand \ escapes (e.g. \u) It might be worth calling out

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

Why not allow string concatenation without plus sign only if/when the implementation becomes optimised to allow compile time concatenation? This makes it crystal clear whether the concatenation is compile time or runtime. If we allow it now, it's hard to tell without looking at the CPython source

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, 5 Sep 2015 at 09:19 Guido van Rossum wrote: > On Sat, Sep 5, 2015 at 2:10 AM, haypo s wrote: > >> 2015-09-05 5:01 GMT+02:00 Guido van Rossum : >> > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a >> > holiday in the US) in case anything unforeseen comes up, but this

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 2:10 AM, haypo s wrote: > 2015-09-05 5:01 GMT+02:00 Guido van Rossum : > > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > > holiday in the US) in case anything unforeseen comes up, but this is > really > > the Last Call for this PEP. > > Would it be

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 1:44 AM, haypo s wrote: > 2015-09-05 5:01 GMT+02:00 Guido van Rossum : > > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > > holiday in the US) in case anything unforeseen comes up, but this is > really > > the Last Call for this PEP. > > String conc

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 8:57 PM, Chris Angelico wrote: >> IMHO the main advantage of allowing expressions inside f-string is >> that it adds something really new compared to the current str.format() >> method. Without it, f-string are less interesting. > > I agree with your conclusion paragraph, >

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sat, Sep 5, 2015 at 7:10 PM, haypo s wrote: > 2015-09-05 5:01 GMT+02:00 Guido van Rossum : >> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a >> holiday in the US) in case anything unforeseen comes up, but this is really >> the Last Call for this PEP. > > Would it be possi

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

2015-09-05 5:01 GMT+02:00 Guido van Rossum : > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > holiday in the US) in case anything unforeseen comes up, but this is really > the Last Call for this PEP. Would it be possible to specify a subset of the Python language allowed i

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 5 September 2015 at 09:44, haypo s wrote: > 2015-09-05 5:01 GMT+02:00 Guido van Rossum : > > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > > holiday in the US) in case anything unforeseen comes up, but this is > really > > the Last Call for this PEP. > > String concat

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

2015-09-05 5:01 GMT+02:00 Guido van Rossum : > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > holiday in the US) in case anything unforeseen comes up, but this is really > the Last Call for this PEP. String concatenation is inefficient in Python because strings are immutab

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

2015-09-05 10:44 GMT+02:00 haypo s : > PEP 498 allows to write >'abc' f'string'< which is replaced with >>'abc' 'string'.__format__()< whereas str+str is a bad practice. Oops, you should read which is replaced with >'abc' + 'string'.__format__()< with a '+' between the two strings. Victor ___

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Fri, Sep 4, 2015 at 6:45 PM, Eric V. Smith wrote: > I've made a number of small changes to PEP 498. I don't think any of the > changes I've made in the last week are substantive. Mostly I've > clarified how it works and removing some limitations. The only > meaningful change is that expression

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On Sep 04 2015, "Eric V. Smith" wrote: > I've made a number of small changes to PEP 498. I don't think any of the > changes I've made in the last week are substantive. Mostly I've > clarified how it works and removing some limitations. The only > meaningful change is that expressions are now surro