Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: string interpolation for python

Reply
Thread Tools

Re: string interpolation for python

 
 
Yingjie Lan
Guest
Posts: n/a
 
      04-02-2012
> You can already do essentially that without adding a special-case string*

> formatting method to the general methods we already have.
>
>>>> balls = 5
>>>> people = 3
>>>> 'The {people} people have{balls}

> balls.'.format(**locals())
> 'The 3 people have 5 balls.'



Clearly dynamic strings are much more powerful,
allowing arbitrary expressions inside. It is also
more terse and readable, since we need no dictionary.

I would probably rather liken dynamic expressions
as a little brother of computable documents*in*
Mathematica. It is a newkind of expression,
rather than formatting -- though it has formatting
connections.*

Dynamic strings are mainly useful at time of
writing readable code before compilation.*
The compiler can choose to convert it into
a string formatting expression, of course.
To efficiently format*strings at runtime,*
the best choice (especially
for safty reasons) is string formatting,*
not evaluating a dynamic string.

On the implementation, I would suppose new*
syntax is needed (though very small).

Yingjie
 
Reply With Quote
 
 
 
 
Jussi Piitulainen
Guest
Posts: n/a
 
      04-02-2012
Yingjie Lan writes:

> Clearly dynamic strings are much more powerful,
> allowing arbitrary expressions inside. It is also
> more terse and readable, since we need no dictionary.

....
> On the implementation, I would suppose new¬*
> syntax is needed (though very small).


I don't think you need any new syntax to implement this.
You can use a syntax like Dynamite("Hello, $world$") now,
similar to fraction.Fraction:

>>> Fraction(3,4) + 1

Fraction(7, 4)

No special syntax there, yet it can be done.
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-02-2012
On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote:

>> You can already do essentially that without adding a special-case
>> string

>
>> formatting method to the general methods we already have.
>>
>>>>> balls = 5
>>>>> people = 3
>>>>> 'The {people} people have {balls}

>> balls.'.format(**locals())
>> 'The 3 people have 5 balls.'

>
>
> Clearly dynamic strings are much more powerful, allowing arbitrary
> expressions inside.


And so it may be a security risk, if user-input somehow ends up treated
as a dynamic string.

We already have three ways to evaluate arbitrary expressions:

* Python code
* eval
* exec

Why do we need yet another one?


> It is also more terse and readable, since we need no
> dictionary.


I think you mean terse and unreadable, since we need no dictionary. That
means that variables will be evaluated by magic from... where? Globals?
Local scope? Non-local scope? All of the above?

We already have one way of evaluating implicit variables using implicit
rules, namely regular Python code. Why do we need a second one?


> I would probably rather liken dynamic expressions as a little brother of
> computable documents¬*in Mathematica. It is a new kind of expression,
> rather than formatting -- though it has formatting connections.


Why do we need a new kind of expression?


> Dynamic strings are mainly useful at time of writing readable code
> before compilation.


What does that mean?


> The compiler can choose to convert it into a string
> formatting expression, of course. To efficiently format¬*strings at
> runtime, the best choice (especially
> for safty reasons) is string formatting, not evaluating a dynamic
> string.


So you're suggesting that we should have dynamic strings, but not
actually use dynamic strings. The compiler should just convert them to
regular string formatting.

Why not cut out the middle-man and just use regular string formatting?



--
Steven
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      04-02-2012
On Mon, Apr 2, 2012 at 6:26 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote:
>> The compiler can choose to convert it into a string
>> formatting expression, of course. To efficiently format*strings at
>> runtime, the best choice (especially
>> for safty reasons) is string formatting, not evaluating a dynamic
>> string.

>
> So you're suggesting that we should have dynamic strings, but not
> actually use dynamic strings. The compiler should just convert them to
> regular string formatting.
>
> Why not cut out the middle-man and just use regular string formatting?


Actually, this sounds like a job for a precompiler/preprocessor. Do
whatever translations you want on your code, then turn it into a .py
file for execution. But hardly necessary, as there are already two -
err, three, I stand corrected - perfectly good ways to do it.

ChrisA
 
Reply With Quote
 
Yingjie Lan
Guest
Posts: n/a
 
      04-02-2012




----- Original Message -----
> From: Steven D'Aprano <(E-Mail Removed)>
> To: http://www.velocityreviews.com/forums/(E-Mail Removed)
> Cc:
> Sent: Monday, April 2, 2012 4:26 PM
> Subject: Re: string interpolation for python
>
> On Mon, 02 Apr 2012 00:39:42 -0700, Yingjie Lan wrote:
>
>>> You can already do essentially that without adding a special-case
>>> string

>>
>>> formatting method to the general methods we already have.
>>>
>>>>>> * balls = 5
>>>>>> * people = 3
>>>>>> * 'The {people} people have {balls}
>>> balls.'.format(**locals())
>>> 'The 3 people have 5 balls.'

>>
>>
>> Clearly dynamic strings are much more powerful, allowing arbitrary
>> expressions inside.

>
> And so it may be a security risk, if user-input somehow ends up treated
> as a dynamic string.
>
> We already have three ways to evaluate arbitrary expressions:
>
> * Python code
> * eval
> * exec
>
> Why do we need yet another one?
>
>
>> It is also more terse and readable, since we need no
>> dictionary.

>
> I think you mean terse and unreadable, since we need no dictionary. That
> means that variables will be evaluated by magic from... where? Globals?
> Local scope? Non-local scope? All of the above?
>
> We already have one way of evaluating implicit variables using implicit
> rules, namely regular Python code. Why do we need a second one?
>
>
>> I would probably rather liken dynamic expressions as a little brother of
>> computable documents*in Mathematica. It is a new kind of expression,
>> rather than formatting -- though it has formatting connections.

>
> Why do we needa new kind of expression?
>
>
>> Dynamic strings are mainly useful at time of writing readable code
>> before compilation.

>
> What does that mean?
>
>
>> The compiler can choose to convert it into a string
>> formatting expression, of course. To efficiently format*strings at
>> runtime, the best choice (especially
>> for safty reasons) is string formatting, not evaluating a dynamic
>> string.

>
> So you're suggesting that we should have dynamic strings, but not
> actually use dynamic strings. The compiler should just convert them to
> regular string formatting.
>
> Why not cut out the middle-man and just use regular string formatting?
>



I believe non of the other three alternatives are as terse and readable.
We've got template based, formattingwith dict, formatting with tuple.
They all require the coder extra effort:

Both template based and dict-based formatting require writing the
identifier three times:

>>> name = 'Peter'
>>> "Are you %(name)s"%{'name':name}

*
If dynamic string is used:
>>> "Are you $name$?"


Template:
>>> Template("Are you $name?").substitute(name=name)


It is three to one in compactness, what a magic 3!

Of course, the old C style way:

>>> "Are you %s?"%name


Almost as terse, but not as readable, especially
when there are many*parts to substitute --
thecoder and reader need to be careful*
to*make sure the sequence is correct.

Why the Python community is so
hostile to new things now?*
Python has merits,
but it is far from being perfect.

Cheers,
Yingjie
 
Reply With Quote
 
Yingjie Lan
Guest
Posts: n/a
 
      04-02-2012
> Actually, this sounds like a job for a precompiler/preprocessor. Do

> whatever translations you want on your code, then turn it into a .py
> file for execution. But hardly necessary, as there are already two -
> err, three, I stand corrected - perfectly good ways to do it.



Agree and disagree.*

The other ways are not perfectly good.
They stinks in Python.*
This new way is the most natural way.
Effortless, natural.That's my Python.

Cheers,
Yingjie

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      04-02-2012
On Mon, Apr 2, 2012 at 7:11 PM, Yingjie Lan <(E-Mail Removed)> wrote:
> I believe non of the other three alternatives are as terse and readable.
> We've got template based, formatting with dict, formatting with tuple.
> They all require the coder extra effort:
>
> Both template based and dict-based formatting require writing the
> identifier three times:
>
>>>> name = 'Peter'
>>>> "Are you %(name)s"%{'name':name}

>
> If dynamic string is used:
>>>> "Are you $name$?"


Yes, it's more compact. But it's also more magic. However, there's an
alternative that's almost as compact. The only requirement is that you
use a two-character token instead of your dollar sign: a double-quote
and a plus.

>>> "Are you "+name+"?"


That allows arbitrary expressions and everything.

> Of course, the old C style way:
>
>>>> "Are you %s?"%name

>
> Almost as terse, but not as readable, especially
> when there are many*parts to substitute --
> the coder and reader need to be careful
> to*make sure the sequence is correct.


I quite like this notation, personally. It's convenient, and is
supported (with variants) in quite a few C-derived languages (and, in
spite of the massive syntactic differences, Python does have C
heritage).

> Why the Python community is so
> hostile to new things now?
> Python has merits,
> but it is far from being perfect.


Hey now, no need to get defensive Thing is, it's up to you to
demonstrate that your proposal justifies itself. You're proposing to
create a massive backward-compatibility issue, so you need to prove
that your new way of formatting strings is sufficiently awesome to be
able to say "Well, you need Python 3.4+ to use this".

ChrisA
 
Reply With Quote
 
Chris Rebert
Guest
Posts: n/a
 
      04-02-2012
On Mon, Apr 2, 2012 at 2:11 AM, Yingjie Lan <(E-Mail Removed)> wrote:
<snip>
> I believe non of the other three alternatives are as terse and readable.
> We've got template based, formatting with dict, formatting with tuple.
> They all require the coder extra effort:
>
> Both template based and dict-based formatting require writing the
> identifier three times:


False. Only once is required, though the technique to achieve it is kinda hacky.

>>>> name = 'Peter'
>>>> "Are you %(name)s"%{'name':name}


"Are you %(name)s" % locals() # or vars()

> If dynamic string is used:
>>>> "Are you $name$?"

>
> Template:
>>>> Template("Are you $name?").substitute(name=name)


Template("Are you $name?").substitute(locals()) # or vars()

> It is three to one in compactness, what a magic 3!

<snip>
> Why the Python community is so
> hostile to new things now?


It's more conservative than hostile. Here's some insight:
http://www.boredomandlaziness.org/20...stalemate.html

Personally, in isolation, the only part of your proposal I find
/truly/ objectionable is the support for arbitrary expressions, since
it would tend towards encouraging suboptimal factoring. But we also
don't live in an ideal world, so the existence of the other 3 (2 of
them particularly relatively similar) alternatives is a legitimate
practical concern when evaluating your proposal. Python is
middle-aged; it's a blessing and a curse.

Cheers,
Chris
 
Reply With Quote
 
Yingjie Lan
Guest
Posts: n/a
 
      04-02-2012
>*

>>>> "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.
As long as people start to realize that
dynamic strings areexpressions,
there is no magic in it any more.

And allowing expressions in those
dynamic strings*would make sense*
since*they are ofthe same sort.

>>> d"sin($x$) = $ sin(x):0.3f $"


is equivalentto 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.

If the computed result is only to be
used in formatting the string, it would
be nice to save an assignment stmt.


>>
>> Almost as terse, but not as readable, especially
>> when there are many*parts to substitute --
>> the coder and reader need to be careful
>> to*make sure the sequence is correct.

>
> I quite like this notation, personally. It's convenient, and is
> supported (with variants) in quite a few C-derived languages (and, in
> spite of the massive syntactic differences, Python does have C
> heritage).


Sure, once you get used to it, it would be harder to stop it
*theharder it is . That's part of human nature, anyway.


>> Why the Python community is so
>> hostile to new things now?
>> Python has merits,
>> but it is far from being perfect.

>
> Hey now, no need to get defensive Thing is, it's up to you to
> demonstrate that your proposal justifies itself. You're proposing to
> create a massive backward-compatibility issue, so you need to prove
> that your new way of formattingstrings is sufficiently awesome to be
> able to say "Well, you need Python 3.4+ to use this".
>



OK. I have put it out as is. I trust people knows good things.

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 alwaysa security issue.

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

Cheers,

Yingjie
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      04-02-2012
On Mon, 02 Apr 2012 02:11:46 -0700, Yingjie Lan wrote:


> Both template based and dict-based formatting require writing the
> identifier three times:


> >>> name = 'Peter'
> >>> "Are you %(name)s"%{'name':name}


They don't *require* this at all.

"Are you %s" % name

For trivial examples, you have trivial syntax. For more complex examples,
you have a more powerful system: % can accept *any* dictionary, so you
aren't limited to just pre-existing variables.

That, by the way, is perhaps the biggest problem with this idea of
dynamic strings: not that it is too powerful, but that it is TOO WEAK. It
can only retrieve names from a single namespace, and the programmer has
no control over which namespace that will be. The only way to feed named
values into the dynamic string is by creating variables.

With existing formatting systems, the programmer has complete control
over what names get used. You can set up a series of separate namespaces
and choose between them as needed:

a = dict(name="Fred", job="butcher")
b = dict(name="Sue", job="SAS sharp-shooter")
c = dict(name="Mary", job="brain surgeon")
d = dict(name="Tony", job="enforcer for the Russian mob")
for namespace in (a, b, c, d):
print ("%(name)s works as a %(job)s." % namespace)


Using your dynamic strings:

for namespace in (a, b, c, d):
name = namespace["name"]
job = namespace["job"]
print ("$name$ works as a $job$.")

and it has the side-effect that it has created some variables that are no
longer needed.

Also notice that because you have to create variables first, the dynamic
string actually requires you to write the identifier MORE times, not
fewer.

So your proposal is actually weaker than what Python already has. So why
bother? All this does is add more things to learn, more complexity in the
compiler and parser, for what? Things that you can already do.


> If dynamic string is used:
> >>> "Are you $name$?"


And where does name come from? It's all too magical. With the existing
format strings, the programmer has *complete* control of where it comes
from:

"Are you %(name)s?" % locals() # from a local variable `name`
"Are you %(name)s?" % globals() # from a global variable `name`
"Are you %(name)s?" % namespace # from any namespace you like

and similar for both format() and Template.


--
Steven
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: string interpolation mystery in Python 2.6 Alan G Isaac Python 4 09-12-2009 11:26 PM
modifying html input date for mysql, reg ex or string interpolation? Kun Python 2 04-11-2006 11:17 PM
Perl/Ruby string interpolation Aiden Humphreys Java 5 05-22-2005 06:37 PM
yet another recipe on string interpolation Michele Simionato Python 8 11-08-2004 08:11 PM
YA string interpolation and printing idea Paul Rubin Python 4 01-19-2004 04:52 PM



Advertisments