> > > > So all of the above leads me to believe that we must have a 100% > > doctest coverage policy. As soon as we start giving out free passes > > people will start to argue that their code should be exempted due to > > BLAH BLAH BLAH and arguing with various people will take longer than > > writing the damn doctest in the first place. Doctests are what enables > > us to develop at this pace and find bugs, i.e. I consider this one a > > huge advantage of Sage and the 100% policy is good for Sage. Just > > imaging how many bugs and leaks will be found by doctesting for > > example the padics code to 100%. That code got in since the consensus > > at SD 7 was that leaving it out would have been painful, but if I were > > confronted with the same problem today I would actually vote -1 on > > merging that code since a year and a couple months after SD 7 when the > > code was merged it is still not properly doctested. > > I agree with all of the above. The *only* functions that I think > don't need a doctest are abstract base class methods whose entire > body is "raise NotImplementedError," and even on this there are lots > of people who would disagree with me. > > - Robert > Regarding this, how does one doctest functions that never return by themselves, like the interfaces' console() function? I noticed that some interfaces even have examples, though they are marked with a # not tested comment, like the one in octave.py
Ronan --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
