> String interopolation should be a *compile time* action, not an > operator. One of the goals, in my mind, is to allow people to string > interpolate without knowing what the locals() function does. After all, > that function is otherwise useless for most Python programmers (and > should probably be moved to an introspection module). > > Your strategy requires the naive user to learn a) the $ syntax, b) the > magic operator syntax and c) the meaning of the locals() function. Plus > you've thrown away the idea that interpolation works as it does in the > shell or in Perl/Awk/Ruby etc. > > At that point, in my mind, we're back where we started and should just > use %. Well have reinvented it with a few small tweaks. > > Plus, operator-based evaluation has some security implications that > compile time evaluation does not. In particular, if the left-hand thing > can be any string then you have the potential of accidentally allowing > the user to supply a string that allows him/her to introspect your local > variables. That can't happen if the interpolation is done at compile > time. All right, but there *also* needs to be a way to invoke interpolation explicitly -- just like eval(). This has applicability e.g. in i18n. --Guido van Rossum (home page: http://www.python.org/~guido/)
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