[Python-Dev] [Python-3000] 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-Dev