[Python-ideas] doctest

[Nick Coghlan]

On Sat, Feb 18, 2012 at 10:43 AM, Devin Jeanpierre
<jeanpierreda at gmail.com> wrote:
> I've in the past worked a bit on improving doctest in a fork I
> started. Its primary purpose was originally to add Cram-like "shell
> doctests" to doctest (see http://pypi.python.org/pypi/cram ), but
> since then I started working on other bits here and there. The work
> I've done is available at
> https://bitbucket.org/devin.jeanpierre/doctest2 (please forgive the
> presumptuous name -- I'm considering a rename to "lembas".)
>
> The reason I've not worked on it recently is that the problems have
> gotten harder and my time has run short. I would be very open to
> collaboration or forking, although I also understand that a largeish
> expansion with redesigned internals created by an overworked student
> is probably not the greatest place to start.
>
> This is all assuming your intentions are to contribute rather than
> only suggest. Not that suggestions aren't welcome, I suppose, but
> maybe not here. doctest is not actively developed or maintained
> anywhere, as far as I know. (I want to say "except by me", because
> that'd make me seem all special and so on, but I haven't committed a
> thing in months.)
>
> Mostly, I feel a bit like this thread could accidentally spawn
> parallel / duplicated work, so I figured I'd put what I have out here.
> Please don't take it for more than it is, doctest2 is still a work in
> progress (and, worse, its source code is in the middle of two feature
> additions!)
>
> I definitely hope you help to make the doctest world better. I think
> it fills a role that should be filled, and its neglect is unfortunate.

Indeed, my apologies for my earlier crankiness (I should know by now
to stay away from mailing lists at crazy hours of the morning).

While it's obviously not the ideal, forking orphaned stdlib modules
and publishing new versions on PyPI can be an *excellent* idea. The
core development team is generally a fairly conservative bunch, so
unless a module has a sufficiently active maintainer that feels
entitled to make API design decisions, our default response to
proposals is going to be "no". One of the *best* ways to change this
is to develop a community around an enhanced version of the module -
one of our reasons for switching to a DVCS for our development was to
help make it easier for people to extract and merge stdlib updates
while maintaining their own versions. Then, when you come to
python-ideas to say "Hey, wouldn't this be a good idea?", it's
possible to point to the PyPI version and say:
- people have tried this and liked it
- I've been maintaining this for a while now and would continue to do
so for the standard library

Some major (current or planned) updates to the Python 3.3 standard
library occurred because folks decided the stdlib solutions were not
in an acceptable state and set out to improve them (specifically, the
packaging package came from the distutils2 fork, which continues as a
backport to early Python versions, and MRAB's regex module has been
approved for addition, although it hasn't actually been incorporated
yet). In the past, other major additions like argparse came about that
way.

A few other stdlib modules have backports on PyPI by their respective
stlib maintainers so we can try out new design concepts *before*
committing to supporting them in the standard library.

A published version of doctest2 that was designed to be suitable for
eventual incorporation back into doctest itself (i.e. by maintaining
backwards compatibility) sounds like it would be quite popular, and
would route around the fact that enhancing it isn't high on the
priority list for the current core development team.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia