[Doc-SIG] fileutils (was Re: simple use of docutils)

David Goodger goodger@users.sourceforge.net
Wed, 16 Oct 2002 21:43:56 -0400


Moore, Paul wrote:
> Actually, I can imagine applications where I'd like all these
> features in general file I/O. Instead of writing docutils-specific
> classes, a better approach would be to write file-object wrappers.
...
> You could write some great pipeline-style code in there...
> 
> I think this is somewhere where restricting the code to docutils is
> a mistake.

The code is currently only used by Docutils, but it's certainly not
*restricted* in any way.  The code is as open as open can be, just
waiting for a champion to run with it.  Will you be that champion? :-)
Is a "fileutils" project in the cards?

> If there are good utilities that docutils needs, but which are not
> docutils-specific, let's package them independently so that the next
> person doesn't reinvent the wheel.

Beware over-generalization though.  Can these file-wrapper utilities
satisfy all (or the great majority) of uses?  Or will developers have
to roll their own anyhow?  I suspect the latter, because requirements
vary so widely.  And it's so easy to roll your own in Python.

I'm sure there are other parts of Docutils that could be extracted and
repurposed for general use.  The statemachine.py module was intended
in this way (in fact, it was a rewrite of an older module I'd written
for general text filtering, so I *know* it's independently useful).
The test/package_unittest.py module's "loadTestModules" function
extends the standard unittest.py to load and run directories full of
test modules; it should be offered back to Python in general.  There
are probably other examples, but I'm too close to the code to notice.

Any volunteers?

> (For an example of a similar situation, distutils has a
> fancy_getopt() which is almost unknown outside of that package -
> this is in spite of the fact that it is just a getopt utility, with
> nothing distutils-specific about it...)

Note that fancy_getopt() has been superceded by Optik
(http://optik.sf.net/), which will be joining the standard library for
Python 2.3, probably as OptionParser.py.  Note also that Docutils is
already using it in the optik.py module (which will be replaced by the
official module once it exists; Optik is currently a package).

-- 
David Goodger  <goodger@users.sourceforge.net>  Open-source projects:
  - Python Docutils: http://docutils.sourceforge.net/
    (includes reStructuredText: http://docutils.sf.net/rst.html)
  - The Go Tools Project: http://gotools.sourceforge.net/