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

[Guido van Rossum]

[Paul]
> 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.

Yes.

> 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.

Yes.

> If "%" survives, it would be used for positional parameters, instead of
> named parameters.

Yes (in Python 3).  I can also see the viewpoint that the printf
syntax should be abandoned entirely (in Python 3), in favor of a
different (and probably more verbose) way to spell things like "%6.3f"
or "%04x".  Although there may be application areas (like producing
output from numeric programs) where the formatting options are very
convenient.  In that case Python 3 could retain the positional %
syntax but drop the by-name syntax.  I'm undecided on this.

> Is that your current thinking on the matter? 

Yes.  But based on a lot of feedback (e.g. Alex's anecdote) I'm
inclined to let the matter rest rather than rush to add a new language
feature.

> 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.

OTOH, there's François's position:

[François]
> The mantra I repeated all along had two key points:
> 
> 1) internationalisation will only be successful if designed to be
>    unobtrusive, otherwise average maintainers and implementors will
>    resist it.
> 
> 2) programmer duties and translation duties are to be kept separate,
>    so these activities could be done asynchronously from one
>    another.[1]
> 
> I really, really think that with enough and proper care, Python
> could be set so internationalisation of Python scripts is just
> unobtrusive routine.  There should not be one way to write Python
> when one does not internationalise, and another different way to use
> it when one internationalises.  The full power and facilities of
> Python should be available at all times, unrelated to
> internationalisation intents.  Non-English people should not have to
> pay a penalty, or if they do, the penalty should be minimised As
> Much As Possible.

However, he fails to suggest even a glimpse of a solution that
satisfies his requirements, so I'm intended to write him off as the
crank he usually is. ;-)

> Our BDFL, Guido, should favour internationalisation as a principle
> in the evolution for the language, that is, more than a random
> negligible feature.  I sincerely hope he will do.  For many people,
> internationalisation issues cannot be separated out that simply, or
> otherwise dismissed.  We should rather learn to collaborate at
> properly addressing and solving them at each evolutionary step, so
> Python really remains a language for everybody.

To the contrary, I think most users don't care about writing code that
can be switched easily from one language to the next.  They only care
about being able to write code that prints text in their own language
(and perhaps about being able to use words in their own language as
identifiers).

--Guido van Rossum (home page: http://www.python.org/~guido/)