>>> 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 item
On Tue, Apr 3, 2012 at 4:56 AM, Steven D'Aprano
wrote:
> On Tue, 03 Apr 2012 00:58:38 +1000, Chris Angelico wrote:
>
>> I can't find a way to use an argument more than once,
>> without switching to "dictionary mode" and using keys for everything.
>
> Ack.
>
> In this case, you can use format:
>
>>
On Apr 2, 2:11 pm, Yingjie Lan 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 fo
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.
On Mar 31, 3:29 am, Terry Reedy wrote:
> On 3/31/2012 2:22 AM, Yingjie Lan wrote:
>
> > Hi all,
>
> > I'd really like to share this idea of string interpolation for formatting.
> > Let's start with some code:
>
> > >>> name = "Shrek"
> > >>> print( "Hi, $name$!")
> > Hi, Shrek!
> > >>> balls =
On Tue, 03 Apr 2012 00:58:38 +1000, Chris Angelico wrote:
> 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
>> 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
dyn
> Right, meaning that both have the same issues
> of performance, need for
> str(), etc. There's absolutely no difference.
OK, performance. Here is a new solution:
Suppose we have a new string method
str.format_join([...])
taking a list of strings and objects,
with even-indexed ones being
mwil...@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 ou
On Mon, Apr 2, 2012 at 9:46 PM, Yingjie Lan 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
> equ
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
> 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 dyna
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
...
> 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
> "Are you %(name)s" % locals() # or vars()
This partly solves the problem, however, you
can't work with expressions inside, like:
> d"sin($x$) = $sin(x)$"
Also, what if locals() or vars() does not contain
the variable "x"? (x could be nonlocal or global).
> It's more conservative than hos
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
>
"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
On Mon, Apr 2, 2012 at 2:11 AM, Yingjie Lan 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 requi
Yingjie Lan 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
On Mon, Apr 2, 2012 at 7:11 PM, Yingjie Lan 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 requir
> 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.
- Original Message -
> From: Steven D'Aprano
> 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 alre
On Mon, Apr 2, 2012 at 6:26 PM, Steven D'Aprano
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)
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(**
On Mon, 02 Apr 2012 17:52:33 +1000, Chris Angelico wrote:
> I'm -1 on the idea, mainly because there are already two perfectly good
> string interpolation syntaxes that don't require a new kind of string.
Three.
% formatting
{} formatting
$ formatting using string.Template
--
Steven
--
http
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 ne
On Mon, Apr 2, 2012 at 5:24 PM, Yingjie Lan wrote:
> They are called "Dynamic strings".
> Dynamic strings can achieve formatting,
> but the mechanism under the hood differ
> from common strings dramatically.
>
> Many here didn't realize that this is not
> another formatting proposal, it is a new
>
> Python already has *3* different built-in string
> formatting/interpolation systems:
...
> I would surmise that your key "implicitly grab variable values from
> the enclosing scope" feature has previously been rejected for being
> too magical.
It grabs because it is an expression in disguise (n
> 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
Hi Adrian, see my comments below.
>
> From: Adrian Hunt
...
>It could break old code... okay you may say you should’nt allow
>certain characters but if they're printable and used in a controlled
>environment those characters can dramatically increase the security
>
On 3/31/2012 2:22 AM, Yingjie Lan wrote:
Hi all,
I'd really like to share this idea of string interpolation for formatting.
Let's start with some code:
>>> name = "Shrek"
>>> print( "Hi, $name$!")
Hi, Shrek!
>>> balls = 30
>>> print( "We have $balls$ balls.")
We have 30 balls
You can alre
Hi Yingjie,
Consider this snippet of "safe" code:
| enc = bobsencryption.Encoder('Some secret key')
|
| username = raw_input('Enter your username:')
| password = raw_input('Enter your password:')
|
| print
| print username + ', please wait while we dial-up and log you in...'
|
| connection = ser
On Fri, Mar 30, 2012 at 11:22 PM, Yingjie Lan wrote:
> Hi all,
>
> I'd really like to share this idea of string interpolation for formatting.
> Let's start with some code:
>
name = "Shrek"
print( "Hi, $name$!")
> Hi, Shrek!
Python already has *3* different built-in string
formatting/int
33 matches
Mail list logo
