On Sat, Feb 18, 2012 at 10:43 AM, Devin Jeanpierre
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@gmail.com | Brisbane, Australia