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). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
