[Python-Dev] [Python-3000] PEP 30XZ: Simplified Parsing (original) (raw)

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-Dev mailing list