<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1256">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">"Point to note: Currently, all the string prefixes are compile-time<br>
directives only. A b"bytes" or u"unicode" prefix affects what kind of<br>
object is produced, and all the others are just syntactic differences.<br>
In all cases, a string literal is a single immutable object which can<br>
be stashed away as a constant. What you're suggesting here is a thing<br>
that looks like a literal, but is actually a run-time operation."<br>
<br>
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.<br>
<br>
Defined as a compile time transform like this, I'm +1. As soon as any suggestion mentions "locals()" or "globals()" I'm -1.<br>
<br>
Cheers,<br>
Steve<br>
<br>
Top-posted from my Windows Phone</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:rosuav@gmail.com">Chris Angelico</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">ý7/ý19/ý2015 16:44</span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Cc:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt"><a href="mailto:python-ideas@python.org">python-ideas@python.org</a></span><br>
<span style="font-family:Calibri,sans-serif; font-size:11pt; font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif; font-size:11pt">Re: [Python-ideas] Briefer string format</span><br>
<br>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On Mon, Jul 20, 2015 at 9:35 AM, Mike Miller <python-ideas@mgmiller.net> wrote:<br>
> I've long wished python could format strings easily like bash or perl do,<br>
> ...<br>
> and then it hit me:<br>
><br>
>     csstext += f'{nl}{key}{space}{{{nl}'<br>
><br>
> An "f-formatted" string could automatically format with the locals dict. Not<br>
> yet sure about globals, and unicode only suggested for now.  Perhaps could<br>
> be<br>
> done directly to avoid the .format() function call, which adds some overhead<br>
> and tends to double the length of the line?<br>
<br>
Point to note: Currently, all the string prefixes are compile-time<br>
directives only. A b"bytes" or u"unicode" prefix affects what kind of<br>
object is produced, and all the others are just syntactic differences.<br>
In all cases, a string literal is a single immutable object which can<br>
be stashed away as a constant. What you're suggesting here is a thing<br>
that looks like a literal, but is actually a run-time operation. As<br>
such, I'm pretty dubious; coupled with the magic of dragging values<br>
out of the enclosing namespace, it's going to be problematic as<br>
regards code refactoring. Also, you're going to have heaps of people<br>
arguing that this should be a shorthand for str.format(**locals()),<br>
and about as many arguing that it should follow the normal name<br>
lookups (locals, nonlocals, globals, builtins).<br>
<br>
I'm -1 on the specific idea, though definitely sympathetic to the<br>
broader concept of simplified formatting of strings. Python's<br>
printf-style formatting has its own warts (mainly because of the cute<br>
use of an operator, rather than doing it as a function call), and<br>
still has the problem of having percent markers with no indication of<br>
what they'll be interpolating in. Anything that's explicit is<br>
excessively verbose, anything that isn't is cryptic. There's no easy<br>
fix.<br>
<br>
ChrisA<br>
_______________________________________________<br>
Python-ideas mailing list<br>
Python-ideas@python.org<br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/">http://python.org/psf/codeofconduct/</a><br>
</div>
</span></font>
</body>
</html>