[Python-ideas] Briefer string format

[Chris Angelico]

On Mon, Jul 20, 2015 at 10:43 AM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> "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.

It'd obviously have to be a compile-time transformation. My point is
that it would, unlike all other forms of literal, translate into a
function call.

How is your "x=x, y=y" version materially different from explicitly
mentioning locals() or globals()? The only significant difference is
that your version follows the scope order outward, where locals() and
globals() call up a specific scope each.

Will an f"..." format string be mergeable with other strings? All the
other types of literal can be (apart, of course, from mixing bytes and
unicode), but this would have to be something somehow different. In
every way that I can think of, this is not a literal - it is a
construct that results in a run-time operation. A context-dependent
operation, at that. That's why I'm -1 on this looking like a literal.

ChrisA