"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@gmail.com> Sent: 7/19/2015 16:44 Cc: python-ideas@python.org<mailto:python-ideas@python.org> Subject: Re: [Python-ideas] Briefer string format On Mon, Jul 20, 2015 at 9:35 AM, Mike Miller <python-ideas@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/