A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2019-June/157823.html below:

[Python-Dev] [PEP 558] thinking through locals() semantics

[Python-Dev] [PEP 558] thinking through locals() semantics [Python-Dev] [PEP 558] thinking through locals() semanticsMRAB python at mrabarnett.plus.com
Sun Jun 2 11:13:33 EDT 2019
On 2019-06-02 13:51, Steven D'Aprano wrote:
> On Sun, Jun 02, 2019 at 11:52:02PM +1200, Greg Ewing wrote:
>> Armin Rigo wrote:
>> >You have the occasional big function that benefits a lot from being
>> >JIT-compiled but which contains ``.format(**locals())``.
>> 
>> There should be a lot less need for that now that we have f-strings.
> 
> I think you're forgetting that a lot of code (especially libraries)
> either have to support older versions of Python, and so cannot use
> f-strings at all, or was written using **locals before f-strings came
> along, and hasn't been touched since.
> 
> Another case where f-strings don't help is when the template is
> dynamically generated.
> 
> It may be that there will be less new code written using **locals() but
> I don't think that the **locals() trick will disappear any time before
> Python 5000.
> 
We've had .format_map since Python 3.2, so why use 
``.format(**locals())`` instead of ``.format_map(locals())``?
More information about the Python-Dev mailing list

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