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

[Stefan Behnel]

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 need to add some text to the discussion section, but I think it's in
> reasonable shape. I have a fully working implementation that I'll get
> around to posting somewhere this weekend.
> 
> >>> def how_awesome(): return 'very'
> ...
> >>> f'f-strings are {how_awesome()} awesome!'
> 'f-strings are very awesome!'
> 
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.

[copying my comment from python-ideas here]

How common is this use case, really? Almost all of the string formatting
that I've used lately is either for logging (no help from this proposal
here) or requires some kind of translation/i18n *before* the formatting,
which is not helped by this proposal either. Meaning, in almost all cases,
the formatting will use some more or less simple variant of this pattern:

result = process("string with {a} and {b}").format(a=1, b=2)

which commonly collapses into

result = translate("string with {a} and {b}", a=1, b=2)

by wrapping the concrete use cases in appropriate helper functions.

I've seen Nick Coghlan's proposal for an implementation backed by a global
function, which would at least catch some of these use cases. But it
otherwise seems to me that this is a huge sledge hammer solution for a
niche problem.

Stefan


___
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/archive%40mail-archive.com

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

[Stefan Behnel]

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 title than
>> "Literal String Formatting".
>>
>> I need to add some text to the discussion section, but I think it's in
>> reasonable shape. I have a fully working implementation that I'll get
>> around to posting somewhere this weekend.
>>
>> >>> def how_awesome(): return 'very'
>> ...
>> >>> f'f-strings are {how_awesome()} awesome!'
>> 'f-strings are very awesome!'
>>
>> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
> 
> [copying my comment from python-ideas here]
> 
> How common is this use case, really? Almost all of the string formatting
> that I've used lately is either for logging (no help from this proposal
> here) or requires some kind of translation/i18n *before* the formatting,
> which is not helped by this proposal either.

Thinking about this some more, the "almost all" is actually wrong. This
only applies to one kind of application that I'm working on. In fact,
"almost all" of the string formatting that I use is not in those
applications but in Cython's code generator. And there's a *lot* of string
formatting in there, even though we use real templating for bigger things
already.

However, looking through the code, I cannot see this proposal being of much
help for that use case either. Many of the values that get formatted into
the strings use some kind of non-trivial expression (function calls, object
attributes, also local variables, sometimes variables with lengthy names)
that is best written out in actual code. Here are some real example snippets:

code.putln(
'static char %s[] = "%s";' % (
entry.doc_cname,
split_string_literal(escape_byte_string(docstr

if entry.is_special:
code.putln('#if CYTHON_COMPILING_IN_CPYTHON')
code.putln(
"struct wrapperbase %s;" % entry.wrapperbase_cname)
code.putln('#endif')

temp = ...
code.putln("for (%s=0; %s < PyTuple_GET_SIZE(%s); %s++) {" % (
temp, temp, Naming.args_cname, temp))
code.putln("PyObject* item = PyTuple_GET_ITEM(%s, %s);" % (
Naming.args_cname, temp))

code.put("%s = (%s) ? PyDict_Copy(%s) : PyDict_New(); " % (
self.starstar_arg.entry.cname,
Naming.kwds_cname,
Naming.kwds_cname))
code.putln("if (unlikely(!%s)) return %s;" % (
self.starstar_arg.entry.cname, self.error_value()))

We use %-formatting for historical reasons (that's all there was 15 years
ago), but I wouldn't switch to .format() because there is nothing to win
here. The "%s" etc. place holders are *very* short and do not get in the
way (as "{}" would in C code templates). Named formatting would require a
lot more space in the templates, so positional, unnamed formatting helps
readability a lot. And the value expressions used for the interpolation
tend to be expressions rather than simple variables, so keeping those
outside of the formatting strings simplifies both editing and reading.

That's the third major real-world use case for string formatting now where
this proposal doesn't help. The niche is getting smaller.

Stefan


___
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/archive%40mail-archive.com

[Python-Dev] Reminder: the "3.5" branch in CPython trunk is now 3.5.1

[Larry Hastings]

As I write this email I'm tagging Python 3.5.0 release candidate 1. This 
is the moment that we switch over to our new experimental workflow, 
where we use Bitbucket and pull requests for all future changesets that 
will get applied to 3.5.0.


The Bitbucket repository isn't ready yet, and I'm still putting the 
final touches on the documentation for the process.  I'll have 
everything ready no later than a day from now.  It'll be posted here, 
and will also go into the Python Dev Guide.  For now changes for 
3.5.0rc2 will just have to wait.



Again: any revisions you check in to the "3.5" branch on 
hg.python.org/cpython right now will go automatically into 3.5.1. They 
will *not* automatically go in to 3.5.0.  The only way to get changes 
into 3.5.0 from this moment forward is by creating a pull request on 
Bitbucket which you convince me to accept.



//arry/

p.s. In case you're curious, the last revision to make it in to 3.5.0rc1 
(apart from the revisions I generate as part of my build engineering 
work) was 202a7aabd4fe.
___
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/archive%40mail-archive.com

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

[Eric V. Smith]

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 format" thread. I'm open to a better title than
> "Literal String Formatting".
> 
> I need to add some text to the discussion section, but I think it's in
> reasonable shape. I have a fully working implementation that I'll get
> around to posting somewhere this weekend.
> 
> >>> def how_awesome(): return 'very'
> ...
> >>> f'f-strings are {how_awesome()} awesome!'
> 'f-strings are very awesome!'
> 
> I'm open to any suggestions to improve the PEP. Thanks for your
> feedback.
> 
> 
> I'd like to see an alternatives section, in particular listing
> alternative prefixes and why they weren't chosen over f. Off the top of
> my head, ones I've seen listed are:
> 
> !
> $

I'll add something, but there's no particular reason. "f" for formatted,
along the lines of 'r' raw, 'b' bytes, and 'u' unicode.

Especially when you want to combine them, I think a letter looks better:
fr'{x} a formatted raw string'
$r'{x} a formatted raw string'

Eric.

___
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/archive%40mail-archive.com

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

[Brett Cannon]

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 better title than
> > "Literal String Formatting".
> >
> > I need to add some text to the discussion section, but I think it's in
> > reasonable shape. I have a fully working implementation that I'll get
> > around to posting somewhere this weekend.
> >
> > >>> def how_awesome(): return 'very'
> > ...
> > >>> f'f-strings are {how_awesome()} awesome!'
> > 'f-strings are very awesome!'
> >
> > I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
> [copying my comment from python-ideas here]
>
> How common is this use case, really? Almost all of the string formatting
> that I've used lately is either for logging (no help from this proposal
> here) or requires some kind of translation/i18n *before* the formatting,
> which is not helped by this proposal either. Meaning, in almost all cases,
> the formatting will use some more or less simple variant of this pattern:
>
> result = process("string with {a} and {b}").format(a=1, b=2)
>
> which commonly collapses into
>
> result = translate("string with {a} and {b}", a=1, b=2)
>
> by wrapping the concrete use cases in appropriate helper functions.
>
> I've seen Nick Coghlan's proposal for an implementation backed by a global
> function, which would at least catch some of these use cases. But it
> otherwise seems to me that this is a huge sledge hammer solution for a
> niche problem.
>

So in my case the vast majority of calls to str.format could be replaced
with an f-string. I would also like to believe that other languages that
have adopted this approach to string interpolation did so with knowledge
that it would be worth it (but then again I don't really know how other
languages are developed so this might just be a hope that other languages
fret as much as we do about stuff).
___
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/archive%40mail-archive.com

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

[Eric V. Smith]

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-string" approach that was the subject of
> > the "Briefer string format" thread. I'm open to a better title than
> > "Literal String Formatting".
> >
> > I need to add some text to the discussion section, but I think it's in
> > reasonable shape. I have a fully working implementation that I'll get
> > around to posting somewhere this weekend.
> >
> > >>> def how_awesome(): return 'very'
> > ...
> > >>> f'f-strings are {how_awesome()} awesome!'
> > 'f-strings are very awesome!'
> >
> > I'm open to any suggestions to improve the PEP. Thanks for your
> feedback.
> 
> [copying my comment from python-ideas here]
> 
> How common is this use case, really? Almost all of the string formatting
> that I've used lately is either for logging (no help from this proposal
> here) or requires some kind of translation/i18n *before* the formatting,
> which is not helped by this proposal either. Meaning, in almost all
> cases,
> the formatting will use some more or less simple variant of this
> pattern:
> 
> result = process("string with {a} and {b}").format(a=1, b=2)
> 
> which commonly collapses into
> 
> result = translate("string with {a} and {b}", a=1, b=2)
> 
> by wrapping the concrete use cases in appropriate helper functions.
> 
> I've seen Nick Coghlan's proposal for an implementation backed by a
> global
> function, which would at least catch some of these use cases. But it
> otherwise seems to me that this is a huge sledge hammer solution for a
> niche problem.
> 
> 
> So in my case the vast majority of calls to str.format could be replaced
> with an f-string. I would also like to believe that other languages that
> have adopted this approach to string interpolation did so with knowledge
> that it would be worth it (but then again I don't really know how other
> languages are developed so this might just be a hope that other
> languages fret as much as we do about stuff).

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 checked: literally 100% of my calls to
%-formatting (older code) or str.format (in newer code) could be
replaced with f-strings. And I think every such use would be an improvement.

I firmly believe that the majority of software written in Python does
not show up on PyPi, but is used internally in corporations. It's not
internationalized or localized: it just exists to get a job done
quickly. This is the code that would benefit from f-strings.

This isn't to say that there's not plenty of code where f-strings would
not help. But I think it's as big a mistake to generalize from my
experience as it is from Stefan's.

Eric.

___
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/archive%40mail-archive.com

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

[Peter Ludemann via Python-Dev]

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 put a lambda on the string to delay evaluation.

It would be nice to be able to mark the formatting as lazy ... maybe
another string prefix character to indicate that? (And would the 2nd
expression in an assert statement be lazy or eager?)

PS: As to Brett's comment about the history of string interpolation ... my
recollection/understanding is that it started with Unix shells and the
"$variable" notation, with the "$variable" being evaluated within "..." and
not within '...'. Perl, PHP, Make (and others) picked this up. There seems
to be a trend to avoid the bare "$variable" form and instead use
"${variable}" everywhere, mainly because "${...}" is sometimes required to
avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")

PPS: For anyone wishing to improve the existing format options, Common
Lisp's FORMAT 
and Prolog's format/2
 have
some capabilities that I miss from time to time in Python.

On 9 August 2015 at 11:22, Eric V. Smith  wrote:

> 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-string" approach that was the subject
> of
> > > the "Briefer string format" thread. I'm open to a better title than
> > > "Literal String Formatting".
> > >
> > > I need to add some text to the discussion section, but I think
> it's in
> > > reasonable shape. I have a fully working implementation that I'll
> get
> > > around to posting somewhere this weekend.
> > >
> > > >>> def how_awesome(): return 'very'
> > > ...
> > > >>> f'f-strings are {how_awesome()} awesome!'
> > > 'f-strings are very awesome!'
> > >
> > > I'm open to any suggestions to improve the PEP. Thanks for your
> > feedback.
> >
> > [copying my comment from python-ideas here]
> >
> > How common is this use case, really? Almost all of the string
> formatting
> > that I've used lately is either for logging (no help from this
> proposal
> > here) or requires some kind of translation/i18n *before* the
> formatting,
> > which is not helped by this proposal either. Meaning, in almost all
> > cases,
> > the formatting will use some more or less simple variant of this
> > pattern:
> >
> > result = process("string with {a} and {b}").format(a=1, b=2)
> >
> > which commonly collapses into
> >
> > result = translate("string with {a} and {b}", a=1, b=2)
> >
> > by wrapping the concrete use cases in appropriate helper functions.
> >
> > I've seen Nick Coghlan's proposal for an implementation backed by a
> > global
> > function, which would at least catch some of these use cases. But it
> > otherwise seems to me that this is a huge sledge hammer solution for
> a
> > niche problem.
> >
> >
> > So in my case the vast majority of calls to str.format could be replaced
> > with an f-string. I would also like to believe that other languages that
> > have adopted this approach to string interpolation did so with knowledge
> > that it would be worth it (but then again I don't really know how other
> > languages are developed so this might just be a hope that other
> > languages fret as much as we do about stuff).
>
> 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 checked: literally 100% of my calls to
> %-formatting (older code) or str.format (in newer code) could be
> replaced with f-strings. And I think every such use would be an
> improvement.
>
> I firmly believe that the majority of software written in Python does
> not show up on PyPi, but is used internally in corporations. It's not
> internationalized or localized: it just exists to get a job done
> quickly. This is the code that would benefit from f-strings.
>
> This isn't to say that there's not plenty of code where f-strings would
> not help. But I think it's as big a mistake to generalize from my
> experience as it is from Stefan's.
>
> Eric.
>
> ___
> 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/pludemann%40google.com
>
___

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

[Brett Cannon]

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 have anything
like Lisp's "special forms", so there doesn't seem to be a way to
implicitly put a lambda on the string to delay evaluation.

It would be nice to be able to mark the formatting as lazy ... maybe
another string prefix character to indicate that? (And would the 2nd
expression in an assert statement be lazy or eager?)


That would require a lazy string type which is beyond the scope of this PEP
as proposed since it would require its own design choices, how much code
would not like the different type, etc.

-Brett


PS: As to Brett's comment about the history of string interpolation ... my
recollection/understanding is that it started with Unix shells and the
"$variable" notation, with the "$variable" being evaluated within "..." and
not within '...'. Perl, PHP, Make (and others) picked this up. There seems
to be a trend to avoid the bare "$variable" form and instead use
"${variable}" everywhere, mainly because "${...}" is sometimes required to
avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")

PPS: For anyone wishing to improve the existing format options, Common
Lisp's FORMAT 
and Prolog's format/2
 have
some capabilities that I miss from time to time in Python.

On 9 August 2015 at 11:22, Eric V. Smith  wrote:

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-string" approach that was the subject
of
> > the "Briefer string format" thread. I'm open to a better title than
> > "Literal String Formatting".
> >
> > I need to add some text to the discussion section, but I think it's
in
> > reasonable shape. I have a fully working implementation that I'll
get
> > around to posting somewhere this weekend.
> >
> > >>> def how_awesome(): return 'very'
> > ...
> > >>> f'f-strings are {how_awesome()} awesome!'
> > 'f-strings are very awesome!'
> >
> > I'm open to any suggestions to improve the PEP. Thanks for your
> feedback.
>
> [copying my comment from python-ideas here]
>
> How common is this use case, really? Almost all of the string
formatting
> that I've used lately is either for logging (no help from this
proposal
> here) or requires some kind of translation/i18n *before* the
formatting,
> which is not helped by this proposal either. Meaning, in almost all
> cases,
> the formatting will use some more or less simple variant of this
> pattern:
>
> result = process("string with {a} and {b}").format(a=1, b=2)
>
> which commonly collapses into
>
> result = translate("string with {a} and {b}", a=1, b=2)
>
> by wrapping the concrete use cases in appropriate helper functions.
>
> I've seen Nick Coghlan's proposal for an implementation backed by a
> global
> function, which would at least catch some of these use cases. But it
> otherwise seems to me that this is a huge sledge hammer solution for a
> niche problem.
>
>
> So in my case the vast majority of calls to str.format could be replaced
> with an f-string. I would also like to believe that other languages that
> have adopted this approach to string interpolation did so with knowledge
> that it would be worth it (but then again I don't really know how other
> languages are developed so this might just be a hope that other
> languages fret as much as we do about stuff).

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 checked: literally 100% of my calls to
%-formatting (older code) or str.format (in newer code) could be
replaced with f-strings. And I think every such use would be an improvement.

I firmly believe that the majority of software written in Python does
not show up on PyPi, but is used internally in corporations. It's not
internationalized or localized: it just exists to get a job done
quickly. This is the code that would benefit from f-strings.

This isn't to say that there's not plenty of code where f-strings would
not help. But I think it's as big a mistake to generalize from my
experience as it is from Stefan's.

Eric.



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth

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

[Peter Ludemann via Python-Dev]

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 too verbose. As far as I can tell, PEP 498
would work with this because it implicitly supports closures — that is,
it's defined as equivalent to
log.info(lambda: ''.join([foo.__format__(), ' just did a ',
bar.__format__(), ' thing']))


On 9 August 2015 at 15:25, Brett Cannon  wrote:

>
> 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 have
> anything like Lisp's "special forms", so there doesn't seem to be a way to
> implicitly put a lambda on the string to delay evaluation.
>
> It would be nice to be able to mark the formatting as lazy ... maybe
> another string prefix character to indicate that? (And would the 2nd
> expression in an assert statement be lazy or eager?)
>
>
> That would require a lazy string type which is beyond the scope of this
> PEP as proposed since it would require its own design choices, how much
> code would not like the different type, etc.
>
> -Brett
>
>
> PS: As to Brett's comment about the history of string interpolation ... my
> recollection/understanding is that it started with Unix shells and the
> "$variable" notation, with the "$variable" being evaluated within "..." and
> not within '...'. Perl, PHP, Make (and others) picked this up. There seems
> to be a trend to avoid the bare "$variable" form and instead use
> "${variable}" everywhere, mainly because "${...}" is sometimes required to
> avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")
>
> PPS: For anyone wishing to improve the existing format options, Common
> Lisp's FORMAT 
> and Prolog's format/2
> 
> have some capabilities that I miss from time to time in Python.
>
> On 9 August 2015 at 11:22, Eric V. Smith  wrote:
>
> 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-string" approach that was the subject
> of
> > > the "Briefer string format" thread. I'm open to a better title than
> > > "Literal String Formatting".
> > >
> > > I need to add some text to the discussion section, but I think
> it's in
> > > reasonable shape. I have a fully working implementation that I'll
> get
> > > around to posting somewhere this weekend.
> > >
> > > >>> def how_awesome(): return 'very'
> > > ...
> > > >>> f'f-strings are {how_awesome()} awesome!'
> > > 'f-strings are very awesome!'
> > >
> > > I'm open to any suggestions to improve the PEP. Thanks for your
> > feedback.
> >
> > [copying my comment from python-ideas here]
> >
> > How common is this use case, really? Almost all of the string
> formatting
> > that I've used lately is either for logging (no help from this
> proposal
> > here) or requires some kind of translation/i18n *before* the
> formatting,
> > which is not helped by this proposal either. Meaning, in almost all
> > cases,
> > the formatting will use some more or less simple variant of this
> > pattern:
> >
> > result = process("string with {a} and {b}").format(a=1, b=2)
> >
> > which commonly collapses into
> >
> > result = translate("string with {a} and {b}", a=1, b=2)
> >
> > by wrapping the concrete use cases in appropriate helper functions.
> >
> > I've seen Nick Coghlan's proposal for an implementation backed by a
> > global
> > function, which would at least catch some of these use cases. But it
> > otherwise seems to me that this is a huge sledge hammer solution for
> a
> > niche problem.
> >
> >
> > So in my case the vast majority of calls to str.format could be replaced
> > with an f-string. I would also like to believe that other languages that
> > have adopted this approach to string interpolation did so with knowledge
> > that it would be worth it (but then again I don't really know how other
> > languages are developed so this might just be a hope that other
> > languages fret as much as we do about stuff).
>
> 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 a

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

[MRAB]

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/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Eric V. Smith]

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 (lambda: f'{foo} just did a {bar} thing')
> 
> It's not pretty, but it's not too verbose. As far as I can tell, PEP 498
> would work with this because it implicitly supports closures — that is,
> it's defined as equivalent to
> log.info (lambda: ''.join([foo.__format__(), ' just did
> a ', bar.__format__(), ' thing']))
> 

That basically works:
class Foo:
def __init__(self, name):
self.name = name

def __format__(self, fmt):
print(f'__format__: {self.name}')
return f'{self.name}'


class Logger:
# accumulate log messages until flush is called
def __init__(self):
self.values = []

def log(self, value):
self.values.append(value)

def flush(self):
for value in self.values:
if callable(value):
value = value()
print(f'log: {value}')

logger = Logger()

f1 = Foo('one')
f2 = Foo('two')
print('before log calls')
logger.log('first log message')
logger.log(lambda:f'f: {f1} {f2}')
logger.log('last log message')
print('after log calls')
f1 = Foo('three')
logger.flush()


produces:

before log calls
after log calls
log: first log message
__format__: three
__format__: two
log: f: three two
log: last log message


But note that when the lambdas are called, f1 is bound to Foo('three'),
so that's what's printed. I don't think that's what the logging module
would normally do, since it wouldn't see the rebinding.

I guess you'd have to change logging to do something special if it had a
single argument which is a callable, or add new interface to it.

And of course you'd have to live with the ugliness of lambdas in the
logging calls.

So, I can't say I'm a huge fan of the approach. But writing examples
using f-strings is way more fun that using %-formatting or str.format!

But it does remind me I still need to implement f'{field:{width}}'.

Eric.
___
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/archive%40mail-archive.com

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

[Eric V. Smith]

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 functions.
>>
>> e.g.:
>> log.info (lambda: f'{foo} just did a {bar} thing')
>>
>> It's not pretty, but it's not too verbose. As far as I can tell, PEP 498
>> would work with this because it implicitly supports closures — that is,
>> it's defined as equivalent to
>> log.info (lambda: ''.join([foo.__format__(), ' just did
>> a ', bar.__format__(), ' thing']))
>>
> 
> That basically works:
> class Foo:
> def __init__(self, name):
> self.name = name
> 
> def __format__(self, fmt):
> print(f'__format__: {self.name}')
> return f'{self.name}'
> 
> 
> class Logger:
> # accumulate log messages until flush is called
> def __init__(self):
> self.values = []
> 
> def log(self, value):
> self.values.append(value)
> 
> def flush(self):
> for value in self.values:
> if callable(value):
> value = value()
> print(f'log: {value}')
> 
> logger = Logger()
> 
> f1 = Foo('one')
> f2 = Foo('two')
> print('before log calls')
> logger.log('first log message')
> logger.log(lambda:f'f: {f1} {f2}')
> logger.log('last log message')
> print('after log calls')
> f1 = Foo('three')
> logger.flush()
> 
> 
> produces:
> 
> before log calls
> after log calls
> log: first log message
> __format__: three
> __format__: two
> log: f: three two
> log: last log message
> 
> 
> But note that when the lambdas are called, f1 is bound to Foo('three'),
> so that's what's printed. I don't think that's what the logging module
> would normally do, since it wouldn't see the rebinding.
> 
> I guess you'd have to change logging to do something special if it had a
> single argument which is a callable, or add new interface to it.
> 
> And of course you'd have to live with the ugliness of lambdas in the
> logging calls.
> 
> So, I can't say I'm a huge fan of the approach. But writing examples
> using f-strings is way more fun that using %-formatting or str.format!

Here's a better example that shows the closure. Same output as above:

class Foo:
def __init__(self, name):
self.name = name

def __format__(self, fmt):
print(f'__format__: {self.name}')
return f'{self.name}'


class Logger:
# accumulate log messages until flush is called
def __init__(self):
self.values = []

def log(self, value):
self.values.append(value)

def flush(self):
for value in self.values:
if callable(value):
value = value()
print(f'log: {value}')

def do_something(logger):
f1 = Foo('one')
f2 = Foo('two')
print('before log calls')
logger.log('first log message')
logger.log(lambda:f'f: {f1} {f2}')
logger.log('last log message')
print('after log calls')
f1 = Foo('three')

logger = Logger()
do_something(logger)
logger.flush()


___
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/archive%40mail-archive.com

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

[David Mertz]

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 checked: literally 100% of my calls to
> %-formatting (older code) or str.format (in newer code) could be
> replaced with f-strings. And I think every such use would be an
> improvement.
>

I'm sure that pretty darn close to 100% of all the uses of %-formatting and
str.format I've written in the last 13 years COULD be replaced by the
proposed f-strings (I suppose about 16 years for me, actually).  But I
think that every single such replacement would make the programs worse.
I'm not sure if it helps to mention that I *did* actually "write the book"
on _Text Processing in Python_ :-).

The proposal just continues to seem far too magical to me.  In the training
I now do for Continuum Analytics (I'm in charge of the training program
with one other person), I specifically have a (very) little bit of the
lessons where I mention something like:

  print("{foo} is {bar}".format(**locals()))

But I give that entirely as a negative example of abusing code and
introducing fragility.  f-strings are really the same thing, only even more
error-prone and easier to get wrong.  Relying on implicit context of the
runtime state of variables that are merely in scope feels very break-y to
me still.  If I had to teach f-strings in the future, I'd teach it as a
Python wart.

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, say `lgb()`, that would let str.format() or
%-formatting pick up the full "what's in scope".  To my mind, that's the
only good thing about the f-string idea.

Yours, David...

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/archive%40mail-archive.com

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

[David Mertz]

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
values from the local scope (or really, the global_local_builtin scope)
makes me worry about readers of code very easily missing what's really
going on within an f-string.

I don't actually care about the code injection issues and that sort of
thing.  I mean, OK I care a little bit, but my actual concern is purely
explicitness and readability.

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_format()

Or

  scope_format('My name is {name}, my age next year is {age+1}')

I realize that these could be completely semantically equivalent... but the
function or method call LOOKS LIKE a runtime operation, while a one letter
prefix just doesn't look like that (especially to beginners whom I might
teach).

The name 'scope_format' is ugly, and something shorter would be nicer, but
I think this conveys my idea.

Yours, David...

On Sun, Aug 9, 2015 at 6: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 hundreds of individual programs,
>> large and small. I just checked: literally 100% of my calls to
>> %-formatting (older code) or str.format (in newer code) could be
>> replaced with f-strings. And I think every such use would be an
>> improvement.
>>
>
> I'm sure that pretty darn close to 100% of all the uses of %-formatting
> and str.format I've written in the last 13 years COULD be replaced by the
> proposed f-strings (I suppose about 16 years for me, actually).  But I
> think that every single such replacement would make the programs worse.
> I'm not sure if it helps to mention that I *did* actually "write the book"
> on _Text Processing in Python_ :-).
>
> The proposal just continues to seem far too magical to me.  In the
> training I now do for Continuum Analytics (I'm in charge of the training
> program with one other person), I specifically have a (very) little bit of
> the lessons where I mention something like:
>
>   print("{foo} is {bar}".format(**locals()))
>
> But I give that entirely as a negative example of abusing code and
> introducing fragility.  f-strings are really the same thing, only even more
> error-prone and easier to get wrong.  Relying on implicit context of the
> runtime state of variables that are merely in scope feels very break-y to
> me still.  If I had to teach f-strings in the future, I'd teach it as a
> Python wart.
>
> 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, say `lgb()`, that would let str.format() or
> %-formatting pick up the full "what's in scope".  To my mind, that's the
> only good thing about the f-string idea.
>
> Yours, David...
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
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/archive%40mail-archive.com

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

[Wes Turner]

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 hundreds of individual programs,
>> large and small. I just checked: literally 100% of my calls to
>> %-formatting (older code) or str.format (in newer code) could be
>> replaced with f-strings. And I think every such use would be an
improvement.
>
>
> I'm sure that pretty darn close to 100% of all the uses of %-formatting
and str.format I've written in the last 13 years COULD be replaced by the
proposed f-strings (I suppose about 16 years for me, actually).  But I
think that every single such replacement would make the programs worse.
I'm not sure if it helps to mention that I *did* actually "write the book"
on _Text Processing in Python_ :-).
>
> The proposal just continues to seem far too magical to me.  In the
training I now do for Continuum Analytics (I'm in charge of the training
program with one other person), I specifically have a (very) little bit of
the lessons where I mention something like:
>
>   print("{foo} is {bar}".format(**locals()))
>
> But I give that entirely as a negative example of abusing code and
introducing fragility.  f-strings are really the same thing, only even more
error-prone and easier to get wrong.  Relying on implicit context of the
runtime state of variables that are merely in scope feels very break-y to
me still.  If I had to teach f-strings in the future, I'd teach it as a
Python wart.

My editor matches \bsym\b, but not locals() or "{sym}"; when I press *.
#traceability

>
> 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, say `lgb()`, that would let str.format() or
%-formatting pick up the full "what's in scope".  To my mind, that's the
only good thing about the f-string idea.

+1. This would be the explicit way to be loose with variable scope and
string interpolation, while maintaining grep-ability.

>
> Yours, David...
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> ___
> 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/wes.turner%40gmail.com
>
___
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/archive%40mail-archive.com

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

[Sven R. Kunze]

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 else than for formatting.


On 09.08.2015 19:22, Eric V. Smith wrote:

On 8/8/2015 9:08 PM, Tim Delaney wrote:

On 8 August 2015 at 11:39, Eric V. Smith mailto:e...@trueblade.com>> 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 need to add some text to the discussion section, but I think it's in
 reasonable shape. I have a fully working implementation that I'll get
 around to posting somewhere this weekend.

 >>> def how_awesome(): return 'very'
 ...
 >>> f'f-strings are {how_awesome()} awesome!'
 'f-strings are very awesome!'

 I'm open to any suggestions to improve the PEP. Thanks for your
 feedback.


I'd like to see an alternatives section, in particular listing
alternative prefixes and why they weren't chosen over f. Off the top of
my head, ones I've seen listed are:

!
$

I'll add something, but there's no particular reason. "f" for formatted,
along the lines of 'r' raw, 'b' bytes, and 'u' unicode.

Especially when you want to combine them, I think a letter looks better:
fr'{x} a formatted raw string'
$r'{x} a formatted raw string'

Eric.

___
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/srkunze%40mail.de


___
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/archive%40mail-archive.com