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

Stephen J. Turnbull stephen at xemacs.org
Thu May 3 19:54:54 CEST 2007

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

More information about the Python-3000 mailing list