Re: pygettext.py extraction of docstrings

>>>>> "MvL" == Martin v Loewis <[email protected]> writes:

    >> As a consequence for gettext, I could live with an xgettext
    >> option --docstrings which extracts *only* the docstrings of a
    >> set of source files.

    MvL> Again, for the application I have in mind (providing online
    MvL> help in the progamming process), that is acceptable. I think
    MvL> for Barry's application, it is not.

Correct, as described in my other message.

    >> The GNU gettext tools are currently being modified to handle
    >> various programming languages. A new flag 'python-format' is
    >> being introduced, with appropriate format string checking in
    >> 'msgfmt'.  xgettext will also have a Python backend, making
    >> pygettext obsolete (except for docstring extraction, for the
    >> time being).

    MvL> It turns out that there is a "batteries included" issue
    MvL> here. I know a few cases where people have been using
    MvL> pygettext just because it was already on their (Windows)
    MvL> system, whereas GNU gettext was not that readily available
    MvL> (you'd need a C compiler to build it). So while most Unix
    MvL> people will switch to GNU gettext for performance reasons
    MvL> (pygettext is slow), I doubt that pygettext will go away
    MvL> anytime soon.

I agree.  That's a good reason why Python also comes with its own
msgfmt.py script (Side note: thank you thank you thank you for
documenting .mo and .po file formats!  What a pain it was to reverse
engineer the undocumented Solaris formats. :).

At the very least, we should make sure that xgettext will sufficiently
fulfill the needs of Python programmers.  It's easier for us to
prototype the Python idiosyncrasies in pygettext, and then describe
our experiences so xgettext can support them.  Also, the more we can
agree on common conventions now, the better in the long run.

Cheers,
-Barry