Draft PEP: string interpolation with backquotes

[phil hunt]

On Mon, 03 Dec 2001 17:41:54 +2328, Fernando Pérez <fperez528 at yahoo.com> wrote:
>phil hunt wrote:
>
>>>>>        "x is $x, f(x) is $f(x)"
>>>>>
>>>>>This to me is readable, unambiguous and very useful.
>>>> 
>>>> To me it implies the same as:
>>>> 
>>>>    "x is %(x)s, f(x) is %(f)s(x)" % { 'x': x, 'f': f}
>>>> 
>>>No.
>> 
>> Wrong. Read what I said closely. I am right on this, beleive me.
>
>Well, no.

Er, yes.

The first four words were "*To* *me* it implies". I was telling you
what I was thinking.

So unless you can read my mind, and know better than I what I think,
I am right on this.

>> If you want Perl-like features, you can always use Perl.
>
>What's wrong in this group every time someone suggests something that 
>even remotely resembles perl there's a fanatic response to it? Cool 
>down. I've used perl a lot, and am sick of it. I don't want python to 
>become perl, but I simply keep an open mind to situations where in 
>real, everyday work, I find it lacking.

But it isn't lacking, this functionality already exists *in a 
preprocessor*.

>And I think the beauty of an open language is precisely that these 
>discussions can be had. But obviously if everytime someone suggests 
>something different (even if they are wrong) your response is to tell 
>them 'if you don't like it get out of here', progress isn't exactly 
>going to be very fast...

What happens if you take a good design like Python and add an assortment
of everyone's favourite language featurees? You get an overcomplicated
language that is hard to learn and hard to maintain programs written 
in it.

>
>> Easy:
>> 
>>    "some %s expression" % really_complex_expression()
>> 
>> What's wrong with that?
>
>Nothing, for *one* expression. What if there's 50 evaluations that 
>need to be done? As I said, *scalability* of the tool is the issue 
>here.
>
>> 
>> Anyway, having complex espressions interleaved with static text,
>> whether you do it the Perl way or the C++ way, makes the code less
>> readable, IMO.
>
>Or in certain cases, more readable. I'm not thinking of writing web 
>pages here (which I know zilch about). But I often write code which 
>analyzes  a lot of scientific data and generates text file summaries 
>of it. It's vastly clearer to be able to write:
>
>" Pos: ($i,$j,$k), Dist = $sqrt(i**2+j**2+k**2), Corr = $C[i][j][k]"

You can do this with Python *as it stands*. E.g:

   f = " Pos: ($i,$j,$k), Dist = $sqrt(i**2+j**2+k**2), Corr = $C[i][j][k]"
   print someFunction(f)

The implementation of someFunction() is left as an exercise to the
reader.



>
>than *any* of the existing alternatives in python. Here it is:
>
>In [23]: itpl(" Pos: ($i,$j,$k), Dist = $sqrt(i**2+j**2+k**2), \
>   ....: Corr = $C[i][j][k]")
>Out[23]= ' Pos: (1,2,3), Dist = 3.74165738677, Corr = 5'
>
>I read that line and I can know exactly what it's doing, what it 
>evaluates and what data it will show. And I can dig out examples 
>where things are 100 times more complicated than this.

I have *no problem* with this at all. It doesn't involve extending
the syntax of python, and incidently demonstrates that Python
already does what you want.

At the moment, when you see a quoted string in Python source code
you know it is a string literal, whose value is fixed at compile
time. Under this proposal, a quoted string will be an expression,
which will be run at run time.

>I honestly think python would be better off with the feature.

Then fork the language or write a preprocessor.

-- 
*** Philip Hunt *** philh at comuno.freeserve.co.uk ***