Guido van Rossum wrote: > > > 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). >... > 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. I think that what I hear you saying is that interpolation should ideally be done at a compile time for simple uses and at runtime for i18n. The compile-time version should have the ability to do full expressions (array indexes and self.members at the very least) and will have access to nested scopes. The runtime version should only work with dictionaries. I think you also said that they should both use named parameters instead of positional parameters. And presumably just for simplicity they would use similar syntax although one would be triggered at compile time and one at runtime. If "%" survives, it would be used for positional parameters, instead of named parameters. Is that your current thinking on the matter? I think we are making progress if we're coming to understand that the two different problem domains (simple scripts versus i18n) have different needs and that there is probably no one solution that fits both. 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