[Python-ideas] Briefer string format

Steve Dower Steve.Dower at microsoft.com
Mon Jul 20 02:43:29 CEST 2015


"Point to note: Currently, all the string prefixes are compile-time
directives only. A b"bytes" or u"unicode" prefix affects what kind of
object is produced, and all the others are just syntactic differences.
In all cases, a string literal is a single immutable object which can
be stashed away as a constant. What you're suggesting here is a thing
that looks like a literal, but is actually a run-time operation."

Why wouldn't this be a compile time transform from f"string with braces" into "string with braces".format(x=x, y=y, ...) where x, y, etc are the names in each pair of braces (with an error if it can't get a valid identifier out of each format code)? It's syntactic sugar for a simple function call with perfectly well defined semantics - you don't even have to modify the string literal.

Defined as a compile time transform like this, I'm +1. As soon as any suggestion mentions "locals()" or "globals()" I'm -1.

Cheers,
Steve

Top-posted from my Windows Phone
________________________________
From: Chris Angelico<mailto:rosuav at gmail.com>
Sent: ‎7/‎19/‎2015 16:44
Cc: python-ideas at python.org<mailto:python-ideas at python.org>
Subject: Re: [Python-ideas] Briefer string format

On Mon, Jul 20, 2015 at 9:35 AM, Mike Miller <python-ideas at mgmiller.net> wrote:
> I've long wished python could format strings easily like bash or perl do,
> ...
> and then it hit me:
>
>     csstext += f'{nl}{key}{space}{{{nl}'
>
> An "f-formatted" string could automatically format with the locals dict. Not
> yet sure about globals, and unicode only suggested for now.  Perhaps could
> be
> done directly to avoid the .format() function call, which adds some overhead
> and tends to double the length of the line?

Point to note: Currently, all the string prefixes are compile-time
directives only. A b"bytes" or u"unicode" prefix affects what kind of
object is produced, and all the others are just syntactic differences.
In all cases, a string literal is a single immutable object which can
be stashed away as a constant. What you're suggesting here is a thing
that looks like a literal, but is actually a run-time operation. As
such, I'm pretty dubious; coupled with the magic of dragging values
out of the enclosing namespace, it's going to be problematic as
regards code refactoring. Also, you're going to have heaps of people
arguing that this should be a shorthand for str.format(**locals()),
and about as many arguing that it should follow the normal name
lookups (locals, nonlocals, globals, builtins).

I'm -1 on the specific idea, though definitely sympathetic to the
broader concept of simplified formatting of strings. Python's
printf-style formatting has its own warts (mainly because of the cute
use of an operator, rather than doing it as a function call), and
still has the problem of having percent markers with no indication of
what they'll be interpolating in. Anything that's explicit is
excessively verbose, anything that isn't is cryptic. There's no easy
fix.

ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas at python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150720/6b35f2a5/attachment-0001.html>


More information about the Python-ideas mailing list