Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #22443 > unrolled thread

Re: string interpolation for python

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 00:39 -0700
    Re: string interpolation for python Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2012-04-02 11:01 +0300
    Re: string interpolation for python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-04-02 08:26 +0000
      Re: string interpolation for python Chris Angelico <rosuav@gmail.com> - 2012-04-02 18:47 +1000
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 02:11 -0700
        Re: string interpolation for python Duncan Booth <duncan.booth@invalid.invalid> - 2012-04-02 10:19 +0000
        Re: string interpolation for python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-04-02 11:54 +0000
          Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 05:40 -0700
            Re: string interpolation for python Laurent Claessens <moky.math@gmail.com> - 2012-04-02 15:02 +0200
              Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 07:25 -0700
              Re: Re: string interpolation for python Evan Driscoll <driscoll@cs.wisc.edu> - 2012-04-02 15:36 -0500
            Re: string interpolation for python mwilson@the-wire.com - 2012-04-02 10:46 -0400
              Re: string interpolation for python mwilson@the-wire.com - 2012-04-02 11:34 -0400
                Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 09:02 -0700
        Re: string interpolation for python rusi <rustompmody@gmail.com> - 2012-04-02 06:04 -0700
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 02:17 -0700
        Re: string interpolation for python alex23 <wuwei23@gmail.com> - 2012-04-02 22:47 -0700
      Re: string interpolation for python Chris Angelico <rosuav@gmail.com> - 2012-04-02 19:56 +1000
      Re: string interpolation for python Chris Rebert <clp2@rebertia.com> - 2012-04-02 03:23 -0700
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 04:46 -0700
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 05:00 -0700
      Re: string interpolation for python Chris Angelico <rosuav@gmail.com> - 2012-04-03 00:58 +1000
        Re: string interpolation for python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-04-02 18:56 +0000
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 08:49 -0700
      Re: string interpolation for python Chris Angelico <rosuav@gmail.com> - 2012-04-03 08:38 +1000
        Re: string interpolation for python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-04-02 23:18 +0000
      Re: string interpolation for python Yingjie Lan <lanyjie@yahoo.com> - 2012-04-02 18:57 -0700

Page 1 of 2  [1] 2  Next page →

#22443 — Re: string interpolation for python

> 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 new kind 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

[toc] | [next] | [standalone]

#22446

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.

[toc] | [prev] | [next] | [standalone]

#22448

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

[toc] | [prev] | [next] | [standalone]

#22449

On Mon, Apr 2, 2012 at 6:26 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> 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

[toc] | [prev] | [next] | [standalone]

#22451

----- Original Message -----
> From: Steven D'Aprano <steve+comp.lang.python@pearwood.info>
> To: python-list@python.org
> 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 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?
> 


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$?"

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 --
the coder 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

[toc] | [prev] | [next] | [standalone]

#22455

Yingjie Lan <lanyjie@yahoo.com> wrote:

> 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!

You can avoid the duplication fairly easily:

>>> name='Peter'
>>> 'Are you {name}?'.format(**vars())
'Are you Peter?'

though if you're doing that it would be better to limit the scope to a 
specific namespace.

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#22460

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

[toc] | [prev] | [next] | [standalone]

#22462

...
> 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. 
...
> and similar for both format() and Template.


Seems you miss understood my notion of dynamic string.
Dynamic strings are expressions in disguise: the things
in between $...$ are plain old expressions (with optional 
formatting specifications). They are evaluated
as if they were outside the dynamic string. We put them
in there to to kill two birds with one stone: 
   1) ease of reading;
   2) place holding.

Cheers,
Yingjie

[toc] | [prev] | [next] | [standalone]

#22464

> Seems you miss understood my notion of dynamic string.
> Dynamic strings are expressions in disguise: the things
> in between $...$ are plain old expressions (with optional
> formatting specifications). They are evaluated
> as if they were outside the dynamic string. We put them
> in there to to kill two birds with one stone:
>     1) ease of reading;
>     2) place holding.


like this one ?

b = dict(name="Sue", job="SAS sharp-shooter")
print "$b['name']$ works as b['job']"

Is it really easier to read that the following ?
"{0} works as {1}".format(b['name'],b['job'])

In the case in which b is an object having "job" and "name" attribute, 
the dynamic string will write

"$b.name$ works as $b.job$"
instead of
"{0}.name works as {0}.job".format(b)

Laurent

[toc] | [prev] | [next] | [standalone]

#22468

> like this one ?

> 
> b = dict(name="Sue", job="SAS sharp-shooter")
> print "$b['name']$ works as b['job']"
> 
> Is it really easier to read that the following ?
> "{0} works as {1}".format(b['name'],b['job'])
> 
> In the case in which b is an object having "job" and "name" 
> attribute, the dynamic string will write
> 
> "$b.name$ works as $b.job$"
> instead of
> "{0}.name works as {0}.job".format(b)
> 


When you already have a dict, the dict-based
formatting would be nice.

>>> "%(name)s works as %(job)s"%b

If it you need to create a dict just for string

formatting, dynamic string would be nice.
Say your object has methods/properties
that fetch things from your database.

>>> class staff:
...@property
...def name(): return 'Peter'
...
>>> t = staff()
>>> vars(t)
{}
>>> t.name
'Peter'
>>> d"Staff name: $t.name$" #note the d"..." format
'Staff name: Peter'

Because of the d"..." format, it won't 
affect old ways of doing things one bit.
Allowing dynamic string wouldn't hurt 
a bit to anything that is already there.

[toc] | [prev] | [next] | [standalone]

#22537

On 01/-10/-28163 01:59 PM, Yingjie Lan wrote:
> Because of the d"..." format, it won't
> affect old ways of doing things one bit.
> Allowing dynamic string wouldn't hurt
> a bit to anything that is already there.

Why don't you just write a function that does it? I think someone 
already suggested this...

   import dynamic_strings       # write this
   d = dynamic_strings.dynamic

   x = 5
   print(d("x=$x$"))

?

Sure, it's not *quite* as pretty as if you could just say d"x=$x$", and 
you might have to do some hacky uglyness in the implementation to get at 
the locals of the calling procedure, but it solves a bazillion problems, 
such as:

1. YOU can do it, instead of hoping it gets into the mainline
    interpreter

2. You can do it NOW, and it will work with "any" version of Python

3. You have the freedom to easily add "eval from *this dictionary* if
    you want, which solves Steven D'Aprano's objection that your
    suggestion is too weak.

4. Languages changes should be viewed suspiciously in general.

Evan

[toc] | [prev] | [next] | [standalone]

#22471

Yingjie Lan wrote:
> Seems you miss understood my notion of dynamic string.
> Dynamic strings are expressions in disguise: the things
> in between $...$ are plain old expressions (with optional
> formatting specifications). They are evaluated
> as if they were outside the dynamic string. 
 In that case you should re-think the delimiters, so that you have something 
that can be nested.  An example (example only, I'm not in love with it as a 
final form):

"A string that gets %(count*spacer%) in the middle"

"A string that gets %(count*%(spacer%)%) in the middle"

	Mel.

[toc] | [prev] | [next] | [standalone]

#22474

mwilson@the-wire.com wrote:

> Yingjie Lan wrote:
>> Seems you miss understood my notion of dynamic string.
>> Dynamic strings are expressions in disguise: the things
>> in between $...$ are plain old expressions (with optional
>> formatting specifications). They are evaluated
>> as if they were outside the dynamic string.
>  In that case you should re-think the delimiters, so that you have
>  something
> that can be nested.  An example (example only, I'm not in love with it as
> a final form):
> 
> "A string that gets %(count*spacer%) in the middle"
> 
> "A string that gets %(count*%(spacer%)%) in the middle"

A less than great example, I guess.  Maybe

> "A string that gets %(count*"-%(spacer%)-"%) in the middle"


	Mel.

[toc] | [prev] | [next] | [standalone]

#22476

>>   In that case you should re-think the delimiters, so that you have

>>   something
>>  that can be nested.  An example (example only, I'm not in love with it 
> as
>>  a final form):

Haven't really thought about that. Nesting is a big 
issue if in the embedded expression, there is another 
dynamic string expression. For example (the first
'%' immediately preceding the first quote denotes
the start of a dynamic string expression)::

>>> first_name, family_name = "Peter", "Johns"
>>> %"Hi $ first_name+%", $family_name$" $!"

'Hi Peter, Johns!'

However, nesting is really cluttering things up and
we should forbid it without loosing power:
The above example can be done without nesting:
>>> >>> %"Hi $ first_name$, $family_name$!"
'Hi Peter, Johns!'

Can you offer an example where nesting is 
better or necessary?

Cheers,
Yingjie

[toc] | [prev] | [next] | [standalone]

#22533

On Apr 2, 2:11 pm, Yingjie Lan <lany...@yahoo.com> wrote:
> Almost as terse, but not as readable, especially...

Hi Yingjie,
Just in case you are not a native speaker of English, 'terse' is a
mildly pejorative word, ie it is not 'good'.  You probably want to use
something like 'concise', or just plain 'short.'

As for your suggestion, Ive nothing much to say: It probably comes
from a perl culture and who is to way which culture is better? Not me
anyway, whenever I look at perl code my head spins...

[No flaming here -- I just dont know perl]

[toc] | [prev] | [next] | [standalone]

#22452

> 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

[toc] | [prev] | [next] | [standalone]

#22572

On Apr 2, 7:17 pm, Yingjie Lan <lany...@yahoo.com> wrote:
> 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.

I believe you're looking for the Python 4k project.

[toc] | [prev] | [next] | [standalone]

#22453

On Mon, Apr 2, 2012 at 7:11 PM, Yingjie Lan <lanyjie@yahoo.com> 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

[toc] | [prev] | [next] | [standalone]

#22456

On Mon, Apr 2, 2012 at 2:11 AM, Yingjie Lan <lanyjie@yahoo.com> 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/2011/02/status-quo-wins-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

[toc] | [prev] | [next] | [standalone]

#22459

> 

>>>>  "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 are expressions,
there is no magic in it any more.

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.

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
 the harder 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 formatting strings 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 always a security issue.

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.

Cheers,

Yingjie

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web