string interpolation for python

[Yingjie Lan]

>>>  I can't find a way to use an argument more than once,

>>>  without switching to "dictionary mode" and using keys for 
>>> everything.


Even in "dictionary mode", the key is spelled more than

once. The "tuple mode" below seems to save some typing. 

However, when there are more and more items to format, 
the readability deteriorates quickly in the "tuple" mode.

Use an argument more than once is, after all, probably a
not-so-often use case.


The "dictionary mode" greatly enhances readability, but 
you have to provide a dict object and make sure the name in 
your formatting string matches the keys in the dictionary.
And this matching requirement is because of information
redundancy in the arrangement. And information redundancy
is often the root of evil for various kinds of trouble.

Dynamic string seems to have the good without redundancy.
And there is no need to build a dict for it. 
However, when there is already the dict for use, 
clearly the dict format is the winner.
>>  Ack.
>> 
>>  In this case, you can use format:
>> 
>>>>>  "Hello {0}, what's up with {1}? Hey, {0} I'm 
> speaking to you!".format
>>  ('George', 'Melissa')
>>  "Hello George, what's up with Melissa? Hey, George I'm 
> speaking to you!"
> 
> Or don't bother with the initial string, and simply pass everything as
> arguments:
> 
> def yingjie_format(*args):
>     it=iter(args)
>     return ''.join(s%next(it,None) for s in it)
> yingjie_format("sin(%s",x,") = %0.3f", sin(x))
> 

That's very nice, thanks!

> So if they're exactly like normal expressions, why not simply use

> normal expressions?


I think use dynamic strings can have these benefits:
1) you less keys (punch less keys).
2) better readability (less clutters)
3) you don't have to explicit convert/format expressions into strings
4) better performance too (adding strings together is generally slow).
 

>>>  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.
>> 
>>  You are really good at that. Maybe not everybody is as
>>  experience as you, and I suppose the learning curve is
>>  kind of hard to climb.
> 
> Yes, it takes some learning to use it. But that's true of everything,
> no less of your magical string interpolation. My point is that simple
> examples should be (and are, with printf formatting) simple, such that
> you only get those more complicated format strings when you're
> actually doing a complicated job (in that case, taking each element of
> an array and using it twice - actually, it was taking the indices of a
> mapping that would end up being passed to the DB query function, thus
> providing values to the :foo :bar variables).
> 

Sure. But if one thing does well on both simple and complex 
situations, why not that thing?

>>  Those expressions are embedded, you don't need eval()
>>  to have the result though. Are we on the same page?
> 
> I can see three implementation paths:
> 
> 1) Language feature. It really *is* just an expression. There's no way
> that a user can provide them, so there's actually no similarity to
> eval. But this requires that Python itself handle things.
> 
> 2) Precompiler. It *becomes* an expression. Again, perfectly safe,
> although I don't know how useful this really is.
> 
> 3) Functoin. As several have suggested, you could do some magic and
> use d("this is a $dollar$ $interpolated$ string") to implement. For
> this, you *will* need eval (or something like it).
> 

Sure. for 1), things can be done most conveniently and efficiently.
for 2), yeah, not sure how useful it is.
for 3), maybe can let str class have a property like: dy.
which can do all the dirty processing. Then we may do:
>>> x = 0
>>> "sin($x$) = $sin(x)$".dy
'sin(0) = 0.0'

Not much burden to use except for the CPU, I suppose.

>>  You mean a translator?
> 
> Yes. It translates your dollar-strings into something that's legal
> Python 3.3 syntax - either calls to a function like I provided above,
> or actual embedded expressions.
> 
>>  The syntax is essential for compatibility.
>>  We must distinguish dynamic strings from common strings.
>>  They will live peacefully together.
>>  (escaping the '$' in normal strings breaks compatibility,
>>  and the consequence of forgetting to escape could be
>>  disastrous, so definitely not an option).
>> 
>>  May be d" is too tiny, $"..." is easier to pick out.
> 
> I don't like the use of symbols like that; can someone, glancing at
> your code, tell whether $ is an operator, a name, or something else?
> The original d is probably better for that.
> 


Yeah, the d is probably better. 

Cheers,
Yingjie