[Python-ideas] Custom string prefixes

[Haoyi Li]

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 at gmail.com>wrote:

> On Mon, May 27, 2013 at 6:41 AM, Göktuğ Kayaalp
> <goktug.kayaalp at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130529/c415c765/attachment-0001.html>