Guido just stopped by--we're all at the PyCon 2019 dev sprints--and we
had a chat about it. Guido likes it but wanted us to restore a little
of the magical behavior we had in "!d": now, = in f-strings will default
to repr (!r), /unless/ you specify a format spec. If you specify a
format spec it will always default to format. And naturally if you
specify an explicit conversion function (!r !s !a) it will use that.
This makes !f irrelevant, so we're removing it.
Here's the thinking: 99% of the time the user will just use {foo=}, and
for that you want repr. After that, 0.99% of the time the user will
want a format spec that applies directly the value. It's exceedingly
unlikely that someone will want a format spec, but want it to apply to
repr(value) and not value itself. So that's /possible/
(f'{foo=!r:20}'). But the default behavior is the most common case at
every step.
"So, is it checked in?" --GvR,
//arry/
On 5/6/19 8:39 PM, Eric V. Smith wrote:
> Last fall Larry Hastings made a suggestion for adding a way to make
> so-called "print-based debugging" easier with f-strings. Basically the
> approach is that f-strings would be able to produce the text of the
> expression and the value of that expression, without repeating the
> expression in the f-sting. No more writing f'foo={foo}, bar={bar}'.
> foo and bar should each only be in there once each!
>
> At PyCon US 2019 I did a lightning talk about this, suggesting the
> syntax of !d, so that if foo="Hello", then f"{foo!d}" would produce
> "foo='Hello'". That is, it's the text of the expression, followed by
> an equal sign, followed by the repr of the expression. I have
> implemented this and a PR exists. Arbitrary expressions are allowed. I
> heard from core devs and end users after this talk, and all were
> positive.
>
> After that lightning talk, Larry and I talked about it some more, and
> for a number of reasons decided that it would make more sense if the
> syntax used an = sign. So we came up with f"{foo=}", which would also
> produce "foo='Hello'".
>
> The reasons for the change are:
> - Having '=' in the expression is a better mnemonic than !d.
> - By not using a conversion starting with !, we can compose = with the
> existing ! conversions, !r, !s, and the rarely used !a.
> - We can let the user have a little more control of the resulting string.
>
> Another thing I like about this approach over !d is that the patch is
> simpler, because there are fewer special cases. And because there are
> fewer special cases in the code, I think the proposal is easier to
> explain than !d (in particular how it interacts (or doesn't!) with
> format specifiers).
>
> There's a good rationale here, along with a PR:
> https://bugs.python.org/issue36817.
>
> My plan is to commit this change before 3.8b1. If anyone would like to
> discuss it at PyCon, I'll be around until about 10:30 am on Tuesday.
> I'll be in the CPython sprint room, and I'll be watching bpo, too.
>
> Eric
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/larry%40hastings.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190507/320fcd01/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4