Re: [Python-Dev] PEP-498: Literal String Formatting

On 8 August 2015 at 11:39, Eric V. Smith wrote: > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string format" thread. I'm open to a better title than > "Literal String Formatting". Thank

Re: [Python-Dev] PEP-498: Literal String Formatting

Please do not change the meaning of the vestigial U''. It was re-added to the language to fix a problem, rebinding it to another meaning introduces new problems. We have plenty of other letters in the alphabet to use. On 8/8/2015 05:34, Nick Coghlan wrote: On 8 August 2015 at 11:39, Eric V.

Re: [Python-Dev] PEP-498: Literal String Formatting

On 9 August 2015 at 00:05, Alexander Walters wrote: > Please do not change the meaning of the vestigial U''. It was re-added to > the language to fix a problem, rebinding it to another meaning introduces > new problems. We have plenty of other letters in the alphabet to use. It's actually being

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8 August 2015 at 19:34, Nick Coghlan wrote: > On 8 August 2015 at 11:39, Eric V. Smith wrote: >> Following a long discussion on python-ideas, I've posted my draft of >> PEP-498. It describes the "f-string" approach that was the subject of >> the "Briefer string format" thread. I'm open to a be

Re: [Python-Dev] PEP-498: Literal String Formatting

... Its adding meaning to something that was intentionally meaningless. Not using u'' has the obvious, immediate benefit of not caring what u'' means in python 3, so one can continue to write polyglot code. Since you are adding new semantics to python 3, use a different letter so that it just

Re: [Python-Dev] PEP-498: Literal String Formatting

Wait a second, the pep itself does not use the vestigial u''... it uses i''. where did u'' come from? On 8/8/2015 11:07, Nick Coghlan wrote: On 9 August 2015 at 00:05, Alexander Walters wrote: Please do not change the meaning of the vestigial U''. It was re-added to the language to fix a pr

Re: [Python-Dev] PEP-498: Literal String Formatting

On 9 August 2015 at 01:16, Alexander Walters wrote: > Wait a second, the pep itself does not use the vestigial u''... it uses i''. > where did u'' come from? The only difference in the PEP is the fact that the iu"" variant calls a different builtin (__interpolateu__ instead of __interpolate__). T

Re: [Python-Dev] PEP-498: Literal String Formatting

As written in the pep, where i'' means 'I have the __interpolate__' method, and iu'' means 'i have the __interpolateu__' method (or that translators should call these methods), is fine, as the meaning of u ('I am unicode, yeah you already knew that') isn't changed. On 8/8/2015 11:07, Nick Cogh

Re: [Python-Dev] PEP-498: Literal String Formatting

Can the discussion of PEP 501 be done in a separate thread? As of right now this thread has not been about PEP 498 beyond Eric's initial email. On Sat, Aug 8, 2015 at 8:56 AM Alexander Walters wrote: > As written in the pep, where i'' means 'I have the __interpolate__' > method, and iu'' means '

Re: [Python-Dev] PEP-498: Literal String Formatting

On Fri, Aug 7, 2015 at 6:39 PM Eric V. Smith wrote: > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string format" thread. I'm open to a better title than > "Literal String Formatting". >

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8 August 2015 at 11:39, Eric V. Smith wrote: > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string format" thread. I'm open to a better title than > "Literal String Formatting". > > I

Re: [Python-Dev] PEP-498: Literal String Formatting

> On Aug 7, 2015, at 6:39 PM, Eric V. Smith wrote: > > I'm open to any suggestions to improve the PEP. Thanks for your feedback. Here's are few thoughts: * I really like the reduction in verbosity for passing in the variable names. * Because of my C background, I experience a little mental hi

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 08 2015, Nick Coghlan wrote: > On 8 August 2015 at 11:39, Eric V. Smith wrote: >> Following a long discussion on python-ideas, I've posted my draft of >> PEP-498. It describes the "f-string" approach that was the subject of >> the "Briefer string format" thread. I'm open to a better title

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 08 2015, Nikolaus Rath wrote: > On Aug 08 2015, Nick Coghlan wrote: >> On 8 August 2015 at 11:39, Eric V. Smith wrote: >>> Following a long discussion on python-ideas, I've posted my draft of >>> PEP-498. It describes the "f-string" approach that was the subject of >>> the "Briefer string

Re: [Python-Dev] PEP-498: Literal String Formatting

Eric V. Smith schrieb am 08.08.2015 um 03:39: > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string format" thread. I'm open to a better title than > "Literal String Formatting". > > I ne

Re: [Python-Dev] PEP-498: Literal String Formatting

Stefan Behnel schrieb am 09.08.2015 um 10:06: > Eric V. Smith schrieb am 08.08.2015 um 03:39: >> Following a long discussion on python-ideas, I've posted my draft of >> PEP-498. It describes the "f-string" approach that was the subject of >> the "Briefer string format" thread. I'm open to a better

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/8/2015 9:08 PM, Tim Delaney wrote: > On 8 August 2015 at 11:39, Eric V. Smith > wrote: > > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, 9 Aug 2015 at 01:07 Stefan Behnel wrote: > Eric V. Smith schrieb am 08.08.2015 um 03:39: > > Following a long discussion on python-ideas, I've posted my draft of > > PEP-498. It describes the "f-string" approach that was the subject of > > the "Briefer string format" thread. I'm open to a

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 1:38 PM, Brett Cannon wrote: > > > On Sun, 9 Aug 2015 at 01:07 Stefan Behnel > wrote: > > Eric V. Smith schrieb am 08.08.2015 um 03:39: > > Following a long discussion on python-ideas, I've posted my draft of > > PEP-498. It describes the "f-s

Re: [Python-Dev] PEP-498: Literal String Formatting

Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do lazy evaluation. Python doesn't have anything like Lisp's "special forms", so there doesn't seem to be a way to implicitly

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev < python-dev@python.org> wrote: Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do lazy evaluation. Python doesn't

Re: [Python-Dev] PEP-498: Literal String Formatting

What if logging understood lambda? (By testing for types.FunctionType). This is outside PEP 498, but there might be some recommendations on how "lazy" evaluation should be done and understood by some functions. e.g.: log.info(lambda: f'{foo} just did a {bar} thing') It's not pretty, but it's not

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-10 01:24, Peter Ludemann via Python-Dev wrote: What if logging understood lambda? (By testing for types.FunctionType). [snip] Why not use 'callable'? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinf

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 8:24 PM, Peter Ludemann wrote: > What if logging understood lambda? (By testing for types.FunctionType). > This is outside PEP 498, but there might be some recommendations on how > "lazy" evaluation should be done and understood by some functions. > > e.g.: > log.info

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/9/2015 9:02 PM, Eric V. Smith wrote: > On 8/9/2015 8:24 PM, Peter Ludemann wrote: >> What if logging understood lambda? (By testing for types.FunctionType). >> This is outside PEP 498, but there might be some recommendations on how >> "lazy" evaluation should be done and understood by some fun

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smith wrote: > > I think it has to do with the nature of the programs that people write. > I write software for internal use in a large company. In the last 13 > years there, I've written literally hundreds of individual programs, > large and small. I just

Re: [Python-Dev] PEP-498: Literal String Formatting

Y'know, I just read a few more posts over on python-ideas that I had missed somehow. I saw Guido's point about `**locals()` being too specialized and magical for beginners, which I agree with. And it's the other aspect of "magic" that makes me not like f-strings. The idea of *implicitly* getting

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 9, 2015 8:14 PM, "David Mertz" wrote: > > On Sun, Aug 9, 2015 at 11:22 AM, Eric V. Smith wrote: >> >> I think it has to do with the nature of the programs that people write. >> I write software for internal use in a large company. In the last 13 >> years there, I've written literally hundr

Re: [Python-Dev] PEP-498: Literal String Formatting

After I read Nick's proposal and pondering over the 'f' vs. 'r' examples, I like the 'i' prefix more (regardless of the internal implementation). The best solution would be "without prefix and '{var}' only" syntax. Not sure if that is possible at all; I cannot remember using '{...}' anywhere

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/10/2015 01:29, Sven R. Kunze wrote: The best solution would be "without prefix and '{var}' only" syntax. Not sure if that is possible at all; I cannot remember using '{...}' anywhere else than for formatting. My JSON string literal 'test fixtures' weep at that idea. _

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 09, 2015, at 06:14 PM, David Mertz wrote: >That said, there *is* one small corner where I believe f-strings add >something helpful to the language. There is no really concise way to spell: > > collections.ChainMap(locals(), globals(), __builtins__.__dict__). > >If we could spell that as,

Re: [Python-Dev] PEP-498: Literal String Formatting

Eric, On 2015-08-07 9:39 PM, Eric V. Smith wrote: [..] 'f-strings are very awesome!' I'm open to any suggestions to improve the PEP. Thanks for your feedback. Congrats for the PEP, it's a cool concept! Overall I'm +1, because a lot of my own formatting code looks like this: 'something .

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: [...] > That said, there *is* one small corner where I believe f-strings add > something helpful to the language. There is no really concise way to spell: > > collections.ChainMap(locals(), globals(), __builtins__.__dict__). I think

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:07 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] >> That said, there *is* one small corner where I believe f-strings add >> something helpful to the language. There is no really concise way to spell: >> >> collections.ChainM

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > Which brought to mind a certain thought. While I don't like: > > f'My name is {name}, my age next year is {age+1}' > > I wouldn't have any similar objection to: > >'My name is {name}, my age next year is {age+1}'.scope_form

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 01:26 PM, Steven D'Aprano wrote: > On Sun, Aug 09, 2015 at 06:54:38PM -0700, David Mertz wrote: > >> Which brought to mind a certain thought. While I don't like: >> >> f'My name is {name}, my age next year is {age+1}' >> >> I wouldn't have any similar objection to: >> >>'My

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: >I think I would be happy with f-strings, or perhaps i-strings if we use >Nick's ideas about internationalisation, and limit what they can evaluate to >name lookups, attribute lookups, and indexing, just like format(). I still think you really

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:31 PM, Barry Warsaw wrote: > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > >> I think I would be happy with f-strings, or perhaps i-strings if we use >> Nick's ideas about internationalisation, and limit what they can evaluate to >> name lookups, attribute lookups, and in

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-10 2:37 PM, Eric V. Smith wrote: Besides, any expression you have to calculate can go in a local that will get >interpolated. The same goes for any !r or other formatting modifiers. In an >i18n context, you want to stick to the simplest possible substitution >placeholders. This is

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:44 PM, Yury Selivanov wrote: > > > On 2015-08-10 2:37 PM, Eric V. Smith wrote: >>> Besides, any expression you have to calculate can go in a local that >>> will get >>> >interpolated. The same goes for any !r or other formatting >>> modifiers. In an >>> >i18n context, you want

Re: [Python-Dev] PEP-498: Literal String Formatting

I know. I elided including the nonexistent `nonlocals()` in there. But it *should* be `lngb()`. Or call it scope(). :-) On Aug 10, 2015 10:09 AM, "Steven D'Aprano" wrote: > On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote: > > [...] > > That said, there *is* one small corner where I b

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith wrote: > On 08/10/2015 02:44 PM, Yury Selivanov wrote: > > On 2015-08-10 2:37 PM, Eric V. Smith wrote: > >> This is why I think PEP-498 isn't the solution for i18n. I'd really like > >> to be able to say, in a debugging context: > >> > >> print('a:{s

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 02:49 PM, Eric V. Smith wrote: > On 08/10/2015 02:44 PM, Yury Selivanov wrote: >> >> >> On 2015-08-10 2:37 PM, Eric V. Smith wrote: Besides, any expression you have to calculate can go in a local that will get > interpolated. The same goes for any !r or other formatting

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015, at 02:49 PM, Eric V. Smith wrote: >It's possible. But my point is that Barry doesn't even want >attribute/item getters for an i18n solution, and I'm not willing to >restrict it that much. Actually, attribute chasing is generally fine, and flufl.i18n supports that. Translators can

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-10 20:23, Guido van Rossum wrote: On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith mailto:e...@trueblade.com>> wrote: On 08/10/2015 02:44 PM, Yury Selivanov wrote: > On 2015-08-10 2:37 PM, Eric V. Smith wrote: >> This is why I think PEP-498 isn't the solution for i18n. I'd r

Re: [Python-Dev] PEP-498: Literal String Formatting

Here are my notes on PEP 498. 1. Title: Literal String Formatting - String Literal Formatting - Format String Expressions ? 2. Let's call them "format strings" not "f-strings". The latter sounds slightly obnoxious, and also inconsistent with the others: r'' r

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015 11:33 AM, "Barry Warsaw" wrote: > > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > > >I think I would be happy with f-strings, or perhaps i-strings if we use > >Nick's ideas about internationalisation, and limit what they can evaluate to > >name lookups, attribute lookups,

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015 4:52 PM, "Nathaniel Smith" wrote: > > On Aug 10, 2015 11:33 AM, "Barry Warsaw" wrote: > > > > On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote: > > > > >I think I would be happy with f-strings, or perhaps i-strings if we use > > >Nick's ideas about internationalisation, and lim

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 09:23:15PM +0200, Guido van Rossum wrote: [...] > Anyway, this generalization from print() is why I want arbitrary > expressions. Wouldn't it be silly if we introduced print() today and said > "we don't really like to encourage printing complicated expressions, but > maybe

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 1:52 PM, David Mertz wrote: > I know. I elided including the nonexistent `nonlocals()` in there. But it > *should* be `lngb()`. Or call it scope(). :-) > On Aug 10, 2015 10:09 AM, "Steven D'Aprano" wrote: > >> On Sun, Aug 09, 2015 at 06:14:18PM -0700, David Mertz wrote:

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 10, 2015 at 2:04 PM, Carl Meyer wrote: > On 08/10/2015 02:49 PM, Eric V. Smith wrote: > > On 08/10/2015 02:44 PM, Yury Selivanov wrote: > >> > >> > >> On 2015-08-10 2:37 PM, Eric V. Smith wrote: > Besides, any expression you have to calculate can go in a local that > will ge

Re: [Python-Dev] PEP-498: Literal String Formatting

base {entry.wrapperbase_cname}; #endif """ if entry.is_special else ''} {(lambda temp, argn: # my kingdom for a let! f""" for ({temp}=0; {temp} on behalf of Stefan Behnel Sent: Sunday, August 9, 2015 04:53 To: python-dev@python.org Subject: Re: [Python-

Re: [Python-Dev] PEP-498: Literal String Formatting

ISAAC J SCHWABACHER schrieb am 11.08.2015 um 01:05: > I don't know about you, but I sure like this better than what you have: > > code.putlines(f""" > static char {entry.doc_cname}[] = "{ > split_string_literal(escape_bytestring(docstr))}"; > > { # nested! > f""" > #if CYTHON_COMPILING_IN_CPY

Re: [Python-Dev] PEP-498: Literal String Formatting

Barry Warsaw writes: > Besides, any expression you have to calculate can go in a local > that will get interpolated. Sure, but that style should be an application programmer choice. If this syntax can't replace the vast majority of cases where the format method is invoked on a literal string w

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 10, 2015, at 11:05 PM, ISAAC J SCHWABACHER wrote: >code.putlines(f""" >static char {entry.doc_cname}[] = "{ >split_string_literal(escape_bytestring(docstr))}"; > >{ # nested! >f""" >#if CYTHON_COMPILING_IN_CPYTHON >struct wrapperbase {entry.wrapperbase_cname}; >#endif >""" if entry.

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 04:12 PM, Mike Miller wrote: > Here are my notes on PEP 498. > > 1. Title: Literal String Formatting > > - String Literal Formatting > - Format String Expressions > ? I like "String Literal Formatting", but let me sleep on it. > 2. Let's call them "format strings" not

Re: [Python-Dev] PEP-498: Literal String Formatting

This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string. If the string was not an f-string, it just returns self. The gettext module can be modified, I think triviall

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/11/2015 11:09 AM, Alexander Walters wrote: > This may seam like a simplistic solution to i18n, but why not just add a > method to string objects (assuming we implement f-strings) that just > returns the original, unprocessed string. If the string was not an > f-string, it just returns self.

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 11, 2015 10:10 AM, "Alexander Walters" wrote: > > This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string. If the string was not an f-string, it just returns self.

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/11/2015 11:16, Eric V. Smith wrote: On 08/11/2015 11:09 AM, Alexander Walters wrote: This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string. If the string was no

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 11, 2015 10:19 AM, "Wes Turner" wrote: > > > On Aug 11, 2015 10:10 AM, "Alexander Walters" wrote: > > > > This may seam like a simplistic solution to i18n, but why not just add a method to string objects (assuming we implement f-strings) that just returns the original, unprocessed string.

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/11/2015 11:28, Wes Turner wrote: On Aug 11, 2015 10:19 AM, "Wes Turner" > wrote: - [ ] review all string interpolation (for "injection") * [ ] review every '%' * [ ] review every ".format()" * [ ] review every f-string (AND LOCALS AND GLOBALS) * every

Re: [Python-Dev] PEP-498: Literal String Formatting

{entry.wrapperbase_cname}; #endif """ if entry.is_special else ''} {(lambda temp, argn: # my kingdom for a let! f""" for ({temp}=0; {temp} on behalf of Stefan Behnel Sent: Sunday, August 9, 2015 04:53 To: python-dev@python.org Subject: Re: [Python-Dev] PEP-498: L

Re: [Python-Dev] PEP-498: Literal String Formatting

Couldn't you just store the original format string at some __format_str__ attribute at the formatted string? Just in case you need it. x = f'{a}' => x = '{}'.format(a) # or whatever it turns out to be x.__format_str__ = '{a}' On 11.08.2015 17:16, Eric V. Smith wrote: On 08/11/2015 11:09 AM,

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/11/2015 01:25 PM, Sven R. Kunze wrote: > Couldn't you just store the original format string at some > __format_str__ attribute at the formatted string? Just in case you need it. > > x = f'{a}' > > => > > x = '{}'.format(a) # or whatever it turns out to be > x.__format_str__ = '{a}' Yes. B

Re: [Python-Dev] PEP-498: Literal String Formatting

On Tue, Aug 11, 2015 at 10:52 AM, Alexander Walters wrote: > On 8/11/2015 11:28, Wes Turner wrote: > > > On Aug 11, 2015 10:19 AM, "Wes Turner" wrote: > > - [ ] review all string interpolation (for "injection") > * [ ] review every '%' > * [ ] review every ".format()" > * [ ] review every

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/11/2015 06:47 AM, Eric V. Smith wrote: 2. Let's call them "format strings" not "f-strings". The latter sounds slightly obnoxious, and also inconsistent with the others: r'' raw string u'' unicode object (string) f'' format string

Re: [Python-Dev] PEP-498: Literal String Formatting

Stefan Behnel wrote: Syntax highlighting and in-string expression completion should eventually help, once IDEs support it. Concerning that, this is going to place quite a burden on syntax highlighters. Doing it properly will require the ability to parse arbitrary Python expressions, or at least

Re: [Python-Dev] PEP-498: Literal String Formatting

that successfully highlights python but not ruby? ijs From: Python-Dev on behalf of Greg Ewing Sent: Tuesday, August 11, 2015 18:34 To: python-dev@python.org Subject: Re: [Python-Dev] PEP-498: Literal String Formatting Stefan Behnel wrote: > Syntax highlighting and in-string expression

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/10/2015 04:05 PM, ISAAC J SCHWABACHER wrote: I don't know about you, but I sure like this better than what you have: code.putlines(f""" static char {entry.doc_cname}[] = "{ split_string_literal(escape_bytestring(docstr))}"; { # nested! f""" #if CYTHON_COMPILING_IN_CPYTHON struc

Re: [Python-Dev] PEP-498: Literal String Formatting

ng literal (in display mode), but you can open it in your favorite editor to see whether the highlighting makes the code clearer. ________ From: Python-Dev on behalf of Ethan Furman Sent: Wednesday, August 12, 2015 18:11 To: python-dev@python.org Subject: Re: [Python

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8 August 2015 at 02:39, Eric V. Smith wrote: > Following a long discussion on python-ideas, I've posted my draft of > PEP-498. It describes the "f-string" approach that was the subject of > the "Briefer string format" thread. I'm open to a better title than > "Literal String Formatting". > > I

Re: [Python-Dev] PEP-498: Literal String Formatting

Thanks, Paul. Good feedback. Triple quoted and raw strings work like you'd expect, but you're right: the PEP should make this clear. I might drop the leading spaces, for a technical reason having to deal with passing the strings in to str.format. But I agree it's not a big deal one way or the

Re: [Python-Dev] PEP-498: Literal String Formatting

On Sun, Aug 16, 2015 at 8:55 PM, Eric V. Smith wrote: > Thanks, Paul. Good feedback. > Indeed, I smiled when I saw Paul's post. > Triple quoted and raw strings work like you'd expect, but you're right: > the PEP should make this clear. > > I might drop the leading spaces, for a technical reaso

Re: [Python-Dev] PEP-498: Literal String Formatting

2015-08-16 7:21 GMT-07:00 Paul Moore : > 2. By far and away the most common use for me would be things like > print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use > str,format() for this, and it's annoyingly verbose. This would be a > big win, and I'm +1 on the PEP for this specif

Re: [Python-Dev] PEP-498: Literal String Formatting

On 17 August 2015 at 05:34, Victor Stinner wrote: > 2015-08-16 7:21 GMT-07:00 Paul Moore : >> 2. By far and away the most common use for me would be things like >> print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use >> str,format() for this, and it's annoyingly verbose. This wou

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/17/2015 03:02 AM, Paul Moore wrote: On 17 August 2015 at 05:34, Victor Stinner wrote: 2015-08-16 7:21 GMT-07:00 Paul Moore : 3. All of the complex examples look scary, but in practice I wouldn't write stuff like that - why would anyone do so unless they were being deliberately obscure?

Re: [Python-Dev] PEP-498: Literal String Formatting

On 17 August 2015 at 12:48, Larry Hastings wrote: > I think this corner of the debate is covered by the "Consenting adults" > guiding principle we use 'round these parts. Precisely. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyt

Re: [Python-Dev] PEP-498: Literal String Formatting

On 08/16/2015 03:37 PM, Guido van Rossum wrote: > On Sun, Aug 16, 2015 at 8:55 PM, Eric V. Smith > wrote: > > Thanks, Paul. Good feedback. > > > Indeed, I smiled when I saw Paul's post. > > > Triple quoted and raw strings work like you'd expect, but you're

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 17, 2015, at 11:02 AM, Paul Moore wrote: >print(f"Iteration {n}: Took {end-start) seconds") This illustrates (more) problems I have with arbitrary expressions. First, you've actually made a typo there; it should be "{end-start}" -- notice the trailing curly brace. Second, what if you

Re: [Python-Dev] PEP-498: Literal String Formatting

On Tue, Aug 18, 2015 at 12:50 AM, Barry Warsaw wrote: > On Aug 17, 2015, at 11:02 AM, Paul Moore wrote: > >>print(f"Iteration {n}: Took {end-start) seconds") > > This illustrates (more) problems I have with arbitrary expressions. > > First, you've actually made a typo there; it should be "{end

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote: >The linters could tell you that you have no 'end' or 'start' just as >easily when it's in that form as when it's written out in full. >Certainly the mismatched brackets could easily be caught by any sort >of syntax highlighter. The rules for f-s

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 17, 2015 at 7:13 AM, Eric V. Smith wrote: > [...] > My current plan is to replace an f-string with a call to .format_map: > >>> foo = 100 > >>> bar = 20 > >>> f'foo: {foo} bar: { bar+1}' > > Would become: > 'foo: {foo} bar: { bar+1}'.format_map({'foo': 100, ' bar+1': 21}) > > The stri

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 17, 2015 at 8:13 AM, Barry Warsaw wrote: > I'm really asking whether it's technically feasible and realistically > possible > for them to do so. I'd love to hear from the maintainers of pyflakes, > pylint, > Emacs, vim, and other editors, linters, and other static analyzers on a > ro

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 16 2015, Paul Moore wrote: > 2. By far and away the most common use for me would be things like > print(f"Iteration {n}: Took {end-start) seconds"). I believe an even more common use willl be print(f"Iteration {n+1}: Took {end-start} seconds") Note that not allowing expressions would tur

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 17, 2015 at 12:23 PM, Nikolaus Rath wrote: > On Aug 16 2015, Paul Moore wrote: > > 2. By far and away the most common use for me would be things like > > print(f"Iteration {n}: Took {end-start) seconds"). > > I believe an even more common use willl be > > print(f"Iteration {n+1}: Too

Re: [Python-Dev] PEP-498: Literal String Formatting

On 8/17/2015 2:24 PM, Guido van Rossum wrote: > On Mon, Aug 17, 2015 at 7:13 AM, Eric V. Smith > wrote: > > [...] > My current plan is to replace an f-string with a call to .format_map: > >>> foo = 100 > >>> bar = 20 > >>> f'foo: {foo} bar: { bar+1}'

Re: [Python-Dev] PEP-498: Literal String Formatting

On Mon, Aug 17, 2015 at 1:26 PM, Eric V. Smith wrote: > [...] > I think it would be possible to create a version of this that works for > both i18n and regular interpolation. I think the open issues are: > > 1. Barry wants the substitutions to look like $identifier and possibly > ${identifier}, a

Re: [Python-Dev] PEP-498: Literal String Formatting

On 17Aug2015 0813, Barry Warsaw wrote: On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote: The linters could tell you that you have no 'end' or 'start' just as easily when it's in that form as when it's written out in full. Certainly the mismatched brackets could easily be caught by any sort of

Re: [Python-Dev] PEP-498: Literal String Formatting

On 17Aug2015 1506, Steve Dower wrote: On 17Aug2015 0813, Barry Warsaw wrote: On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote: The linters could tell you that you have no 'end' or 'start' just as easily when it's in that form as when it's written out in full. Certainly the mismatched bracket

Re: [Python-Dev] PEP-498: Literal String Formatting

On 2015-08-17 23:06, Steve Dower wrote: On 17Aug2015 0813, Barry Warsaw wrote: On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote: The linters could tell you that you have no 'end' or 'start' just as easily when it's in that form as when it's written out in full. Certainly the mismatched brack

Re: [Python-Dev] PEP-498: Literal String Formatting

On Aug 17, 2015 2:23 PM, "Nikolaus Rath" wrote: > > On Aug 16 2015, Paul Moore wrote: > > 2. By far and away the most common use for me would be things like > > print(f"Iteration {n}: Took {end-start) seconds"). > > I believe an even more common use willl be > > print(f"Iteration {n+1}: Took {end

Re: [Python-Dev] PEP-498: Literal String Formatting

Barry Warsaw writes: > On Aug 17, 2015, at 11:02 AM, Paul Moore wrote: > > >print(f"Iteration {n}: Took {end-start) seconds") > > This illustrates (more) problems I have with arbitrary expressions. > > First, you've actually made a typo there; it should be > "{end-start}" -- notice