[Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing

[Stephen J. Turnbull]

Michael Sparks writes:

 > We generate our component documentation based on going through the AST
 > generated by compiler.ast, finding doc strings (and other strings in
 > other known/expected locations), and then formatting using docutils.

Are you talking about I18N and gettext?  If so, I'm really lost ....

 > You could special case "12345" + "67890" as a compile timeconstructor and 
 > jiggle things such that by the time it came out the parser that looked like 
 > "1234567890", but I don't see what that has to gain over the current form. 

I'm not arguing it's a gain, simply that it's a case that *should* be
handled by extractors of translatable strings anyway, and if it were,
there would not be an I18N issue in this PEP.

It *should* be handled because this is just constant folding.  Any
half-witted compiler does it, and programmers expect their compilers
to do it.  pygettext and xgettext are (very special) compilers.  I
don't see why that expectation should be violated just because the
constants in question are translatable strings.

I recognize that for xgettext implementing that in C for languages as
disparate as Lisp, Python, and Perl (all of which have string
concatenation operators) is hard, and to the extent that xgettext is
recommended by 9 out of 10 translators, we need to worry about how
long it's going to take for xgettext to get fixed (because it *is*
broken in this respect, at least for Python).