[Python-Dev] String substitution: compile-time versus runtime

Paul Prescod paul@prescod.net
Thu, 20 Jun 2002 20:05:17 -0700

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

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

 Paul Prescod