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:

- XML templates
- SQL queries
- Regexes
- Parser Grammers (e.g. Parsimonious)

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:

my_sql_query = sql(...)

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). 

-Haoyi


On Wed, May 29, 2013 at 3:23 PM, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
On Mon, May 27, 2013 at 6:41 AM, Göktuğ Kayaalp
<goktug.kayaalp@gmail.com> wrote:
> I think it would add some significant flexibility to Python to let users
> define custom string prefixes. What I mean by a string prefix is,
> a letter prefixing the string literal, modifying the behavior of it,
--snip--

Rather than Decimal, IMO a more compelling use case is SQL queries. At
the moment, string literals make unsafe string formatting an
attractive nuisance:

    cur.execute("..." % (...))

versus

    cur.execute("...", (...))

Something that custom string prefixes do, that cannot be done in
Python, is make this confusion impossible. You could make the only way
to create passable SQL expressions via the string sql:"...", which
produces an SQL object. At no point in time does the programmer deal
with strings that can be manipulated in unsafe ways to result in SQL
injection vulnerabilities.

Of course, then there is the issue of "what if you want to produce an
SQL expression from a string"? Then you can make that difficult,
rather than attractive, perhaps requiring the following code:

    with sql.unsafe.disable_all_security_protections:
        expr = sql.unsafe.compile_string(my_string)
    cur.execute(expr, (...))

As it stands today, it's very common for people to produce insecure
code completely by accident. I see it on a regular basis in #python.
There is no way to resolve this without something similar to E's
quasiliterals, or these prefixed strings.

-- Devin
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
http://mail.python.org/mailman/listinfo/python-ideas