On Tue, 15 Jan 2002, Paul Prescod wrote: >I think that if we're going to do string interpolation we might as go >all of the way and have one unified string interpolation model. Nice pie in the sky; my comments inserted below. > 1. There should be no string-prefix. Instead the string \$ should be >magical in all non-raw literal strings as \x, \n etc. are. (if you want >to do string interpolation on a raw string, you could do it using the >method version below) +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). > 2. There should be a transition period where literal strings containing >"\$" are flagged. This is likely rare but may occur here and there. And >by the way, unused \-sequences should probably be proactively reserved >now instead of silently "failing" as they do today. What's the use of >making "\" special if sometimes it isn't special? +1 on making undefined \-sequences raise SyntaxError. > 3. I think that it would be clearest if any expression other than a >simple variable name required "\$(parens.around.it())". But that's a >minor decision. +1 on parens, but see my comments to (1). > 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 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. > 5. The interpolation functionality is useful enough to be available for >use on runtime-generated strings. But at runtime it should have a >totally different syntax. Now that Python has string methods it is clear >that "%" could (and IMO should) have been implemented that way: > >newstr = mystr.interp(variabledict, evaluate_expressions=0) > >By default evaluate_expressions is turned off. That means that all it >does is look up variables in the dictionary and insert them into the >string where it seems \$. If you want full interpretation behaviour you >would flip the evaluate_expressions switch. May Guido have mercy on your >soul. -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. /Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4