On Tue, 15 Jan 2002, Paul Prescod wrote:
Paul Svensson wrote:
....
+1 on no prefix, -0 on \$. To my eyes, \(whatever) looks much cleaner, tho I'm not sure how that would work with the evaluate_expressions flag in (5).
An offline correspond suggested that and also suggested perhaps \`. \` is nicely reminicent of `abc` and it does basically the same thing, only in strings, so I kind of like it.
`5+3` '8' "\`5 + 3` is enough" 8 is enough
The downside is that larger characters like $ and % are much more clear to my eyes. Plus there is the whole apos-backtick confusion.
I thought of \` as well, but didn't suggest it, mainly for those reasons.
The problem with \( is that that is likely to already be a popular string in regular expressions.
In which case it should either be a raw string, or spelled \\(. (We _really_ need to issue syntax errors on undefined \-sequences)
...
4. Between the $-sign and the opening paren, it should be possible to put a C-style formatting specification.
"pi = \$5.3f(math.pi)".
There is no reason to force people to switch to a totally different language feature to get that functionality. I never use it myself but presume that scientists do!
Eek -- feeping creaturism. -2.
The feature is already there and sometimes used. We either keep two different ways to spell interpolation or we incorporate it.
I don't think interpolation and variable formatting are similar enough to conflate in a single notation -- wasn't it the ungainliness of using the existing variable formatting to interpolate that started this thread ?
The only reason to add this here is to be able to remove the % operator on strings, and I'm not convinced that is the right way to go. Anyways, this just begs to be spelled something like \%5.3f(math.pi). Printf-like format specifications without a %-character seems just weird.
The offline correspondant also had this idea and I'm coming around to it.
I'm not particularly happy with that idea; simply mimicking the syntax it was supposed to replace, for little gain. I also think there could be some cause for confusion between \%(foo)s looking in vars() and %(foo)s using the other side of the % operator.
... -0. Here I think is a good place to draw the line before the returns diminish too far. I see the major part of the usefulness of string interpolation coming from compile time usage, and that also nicely matches how all other \-sequences are handled.
And do what to do templating at runtime? Modulo? string.replace? Or just don't provide that feature? Also, how to handle interpolation in raw strings?
Since the whole point of raw strings is to _not_ touch what's inside the quotes, I don't see how string interpolation makes much sense there. As for runtime templating, a string method to replace \-sequences seems like a very straightforward idea, that shouldn't need much discussion. Call it "".eval([globals, [locals]]), to get some educational synergy from teaching all the newbies not to give unchecked user input to eval(). I still think compile-time templating would be the more common use, and thus should be the driving issue behind the design. /Paul