[Python-ideas] Briefer string format

[Nick Coghlan]

On 20 July 2015 at 10:43, 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.

I'm opposed to a special case compile time transformation for string
formatting in particular, but in favour of
clearly-distinct-from-anything-else syntax for such utilities:
https://mail.python.org/pipermail/python-ideas/2015-June/033920.html

It would also need a "compile time import" feature for namespacing
purposes, so you might be able to write something like:

    from !string import format # Compile time import

    # Compile time transformation that emits a syntax error for a
malformed format string
    formatted = !format("string with braces for {name} {lookups}
transformed to a runtime <this str>.format(name=name, lookups=lookups)
call")

    # Equivalent explicit code (but without any compile time checking
of format string validity)
    formatted = "string with braces for {name} {lookups} transformed
to a runtime <this str>.format(name=name, lookups=lookups)
call".format(name=name, lookups=lookups)

The key for me is that any such operation *must* be transparent to the
compiler, so it knows exactly what names you're looking up and can
generate the appropriate references for them (including capturing
closure variables if necessary).

If it's opaque to the compiler, then it's no better than just using a
string, which we can already do today.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia