R. David Murray added the comment:

I've given this some more thought, and I'm leaning toward Antoine's POV here.

The point of running the doctests in the docs is not to test python, but to 
test the docs.  Sphinx has a facility to do that: make doctest.  So I think it 
is better to use that doc-specific infrastructure to test the docs.  This also 
allows us to use the full Sphinx facilities to work with those doctests, which 
includes hiding the not-necessary-for-docs bits.

I think we should be moving *away* from having special infrastructure in 
regrtest.  As much stuff as makes sense should be moved to unittest, and we've 
been slowly doing that.  Correspondingly, we should use Sphinx's native test 
facilities, not add special stuff to regrtest.  If Sphinx doesn't have the 
ability to run individual files, we should add that ability to Sphinx, not 
regrtest.  (Note: I personally do not use the ability recently added to 
regrtest to select unit tests from the command line, instead I use the unittest 
CLI directly, and I think that's the better way to do it.  IMO regrtest should 
be focused on running the test *suite*, not on running individual tests.)

Once we've refined the docs so that 'make doctest' runs cleanly, we should 
automate the testing of the docs in some fashion.  One way to do that would be 
to define a test module that handles the interfacing with Sphinx, and is 
controlled by a resource that is *not* included in -uall, and is then 
explicitly enabled on certain buildbots.

Doctests in module files could be handled the same way: build a test module 
that does whatever autodiscovery is needed, and control it via a resource not 
included in -uall.  (I am, however, open to the argument that this one should 
be included in -uall.)

Again, there already exists a way to invoke individual files, using the native 
doctest facilities.  So adding hooks to regrtest is not really needed, IMO.  
Also again, if the doctest CLI is lacking, the improvement should go into 
doctest.

IMO :)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15629>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to