On 20 July 2015 at 10:43, Steve Dower <Steve.Dower@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@gmail.com | Brisbane, Australia