string interpolation for python

[Chris Angelico]

On Mon, Apr 2, 2012 at 9:46 PM, Yingjie Lan <lanyjie at yahoo.com> wrote:
>>>>>  "Are you "+name+"?"
>>
>> That allows arbitrary expressions and everything.
>>
>
> To make that work for any type, you need:
>
>>>> "Are you "+ str(name) + "?"
>
> Another concern is performance.
>
> You are absolutely right, they are
> equivalent in that both are expressions.

Right, meaning that both have the same issues of performance, need for
str(), etc. There's absolutely no difference.

> As long as people start to realize that
> dynamic strings are expressions,
> there is no magic in it any more.

And no benefit. You lose out on syntax highlighting in your editor and
gain nothing.

> And allowing expressions in those
> dynamic strings would make sense
> since they are of the same sort.
>
>>>> d"sin($x$) = $ sin(x):0.3f $"
>
> is equivalent to the expression of
>
>>>> "sin(%s"%x + ")= %0.3f"%sin(x)
>
> Comparing th e two, I would say the latter
> is more computer friendly while
> the former, more human friendly.

The former is more magical, the second is more explicit. Computers do
tend to like the explicit, but I wouldn't assume that humans like the
magical *necessarily*. There are times when we prefer the explicit,
too.

> Sure, once you get used to it, it would be harder to stop it
>  the harder it is :). That's part of human nature, anyway.

Maybe. But it (percent-notation) is expressive and insanely powerful.
Moreover, it obeys the rule that you pay for the complexity you use,
no more and no less. (Although I think there's one lack in Python's
implementation - I can't find a way to use an argument more than once,
without switching to "dictionary mode" and using keys for everything.
I can't, for instance, use "Hello hello, %s %[0]s!"%name to use the
name twice. But since that isn't in the original C implementation,
it's hardly mandatory.)

Some implementations go even further than Python's does and allow an
array notation.

sprintf("UPDATE tablename SET modified=now()%{,%s=:%[0]s%} WHERE
key=%d",array_of_field_names,primary_key_value)
--> "UPDATE tablename SET modified=now(),foo=:foo,bar=:bar,quux=:quux
WHERE key=1234"

You're still paying for no complexity you aren't actually using. It's
clear and readable.

> I would simply say: this new way is much more simple
> and much more powerful. And there is no security issues
> as long as you don't use the evil eval to evaluate expressions,
> which is always a security issue.

It's powerful only if you use eval to allow full expression syntax.
Otherwise, what does it have above str.format()?

> It is new, and has no compatibility issues with old ways at all.
> In syntax, all you need is to allow d"...", which clearly won't
> affect any old ways of business.

You may well be able to get past the compatibility issues. I'm not yet
convinced that the new syntax is worth it, but it may be possible.

Here's a recommendation: Write a parser for your notation that turns
it into executable Python code (that is, executable in Python 3.3
without any d"..." support). Since a dynamic string is really an
expression in disguise, it doesn't need to be translated at run time,
and in fact is best translated at compile time. It wouldn't be hard to
make the precompiler as per your equivalency above; and since you can
use "%s"%123 without raising TypeError, you don't even have to figure
out data types. With that written, the Python community can more
adequately evaluate your proposal, and even start making use of it and
getting a "feel" for the new syntax. If it catches on, someone'll
probably invite you to write a PEP or something; if it doesn't, well,
you still have it on your own version, and you don't have to worry
about upgrades (your precompiler/"patch" should be able to slide up to
a new version easily).

I'm still against the idea personally, mainly because it's nothing but
a more magical way of doing what we already can do, but there may well
be many who disagree.

Chris Angelico