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. 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) >>> from __future__ import string_interp >>> a = "acos(.5) = \$(acos(.5))" Embrace the __future__! 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? 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. 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! 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. 6. People should be discouraged from using the "%" version. Some day far in the future it could be officially deprecated. We'll tell our children stories about the days when we modulo'd strings, tuples and dictionaries in weird and wonderful ways. Once the (admittedly long) transition period is over, we would simply have a better way to do everything we can do today. Code using the new model will be easier to read, more concise, more consistent, more like other scripting languages, abuse syntax less and use fewer logical concepts. Arguably, functions like vars(), locals() and globals() could be relegated to an "introspection" module where no newbie will ever look at them again. (okay, now I'm over-reaching) There will undoubtedly be language-change backlash. Guido will take the heat, not me. He would have to decide if it was worth the pain. I think, however, that the resulting language would be an improvement for experts and newbies alike. And as with other changes -- sooner is better than later. The year after next year is going to be the Year of Python so let's get our changes in before then! Paul Prescod
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