<div dir="ltr">I disagree; I don't think adding an additional language feature to make it harder to do a single thing (i.e. using % on string literals) isn't really worth it on its own. I think the main benefit of doing the process-at-import-time-and-intern thing using custom prefixes is that in a lot of cases, the magic strings you find in python programs aren't really magic data, but instead they're code. Things like:<div style>

<br></div><div style>- XML templates</div><div style>- SQL queries</div><div style>- Regexes</div><div style>- Parser Grammers (e.g. Parsimonious)</div><div style><br></div><div style>may be in a funny syntax (which is why it needs to be put into a string), but fundamentally they are code just like the rest of the python programs, so it makes sense that they'd be compiled and interned at import-time like the rest of the python code. Granted, you can always do:</div>

<div style><br></div><div style>my_sql_query = sql(...)</div><div style><br></div><div style>in the top level namespace to basically do the same thing manually, but that's basically manually spaghettifying your program by shifting pieces of code from where they're used (e.g. inside a loop, inside a function, inside an object) to somewhere far away (the global namespace). Not for any abstraction (e.g. wanting to use the query in more than once place), not for neatness, but purely in exchange for the added performance (it can be quite expensive re-parsing a big xml template each time). </div>

<div style><br></div><div style>-Haoyi</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 3:23 PM, Devin Jeanpierre <span dir="ltr"><<a href="mailto:jeanpierreda@gmail.com" target="_blank">jeanpierreda@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, May 27, 2013 at 6:41 AM, Göktuğ Kayaalp<br>
<<a href="mailto:goktug.kayaalp@gmail.com">goktug.kayaalp@gmail.com</a>> wrote:<br>
> I think it would add some significant flexibility to Python to let users<br>
> define custom string prefixes. What I mean by a string prefix is,<br>
> a letter prefixing the string literal, modifying the behavior of it,<br>
</div>--snip--<br>
<br>
Rather than Decimal, IMO a more compelling use case is SQL queries. At<br>
the moment, string literals make unsafe string formatting an<br>
attractive nuisance:<br>
<br>
    cur.execute("..." % (...))<br>
<br>
versus<br>
<br>
    cur.execute("...", (...))<br>
<br>
Something that custom string prefixes do, that cannot be done in<br>
Python, is make this confusion impossible. You could make the only way<br>
to create passable SQL expressions via the string sql:"...", which<br>
produces an SQL object. At no point in time does the programmer deal<br>
with strings that can be manipulated in unsafe ways to result in SQL<br>
injection vulnerabilities.<br>
<br>
Of course, then there is the issue of "what if you want to produce an<br>
SQL expression from a string"? Then you can make that difficult,<br>
rather than attractive, perhaps requiring the following code:<br>
<br>
    with sql.unsafe.disable_all_security_protections:<br>
        expr = sql.unsafe.compile_string(my_string)<br>
    cur.execute(expr, (...))<br>
<br>
As it stands today, it's very common for people to produce insecure<br>
code completely by accident. I see it on a regular basis in #python.<br>
There is no way to resolve this without something similar to E's<br>
quasiliterals, or these prefixed strings.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Devin<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-ideas" target="_blank">http://mail.python.org/mailman/listinfo/python-ideas</a><br>
</div></div></blockquote></div><br></div>