> Using compile-time parsing, as in PEP 215, has the advantage that it > avoids any possible security problems; It is also the only way to properly support nested scopes. It would be confusing and inconsistent if you can use a variable from a nested scope in an expression but not in a "string display" (which I think is a cute name for strings with embedded expressions). > but it also eliminates the possibility of using this for > internationalization. I see this as the key tension in the string > interpolation issue (aside from all the syntax stuff -- which is > naturally controversial). Yes, I believe that Barry's main purpose is i18n. But I think i18n should not be approached in a cavalier way. If you need i18n of your application, you have to be very disciplined anyway. I think collecting the variable available for interpolation in a dict and passing them explicitly to an interpolation function is the way to go here. Also, in i18n the interpolation syntax must be usable for translators who are not necessarily programmers. I believe the $ notation with only simple variables is entirely adequate for that purpose -- and Barry can implement it in a few lines. (We just adopted this for Zope3, and while there are all sorts of open issues, $ interpolation is not one of them.) --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