[Numpy-discussion] Doctest items
Tue Jul 1 19:19:14 CDT 2008
Robert Kern wrote:
> On Tue, Jul 1, 2008 at 17:50, Fernando Perez <firstname.lastname@example.org> wrote:
>> On Tue, Jul 1, 2008 at 1:41 PM, Pauli Virtanen <email@example.com> wrote:
>>> But it's a custom tweak to doctest, so it might break at some point in
>>> the future, and I don't love the monkeypatching here...
>> Welcome to the joys of extending doctest/unittest. They hardcoded so
>> much stuff in there that the only way to reuse that code is by
>> copy/paste/monkeypatch. It's absolutely atrocious.
>>>> We could always just make the plotting section one of those "it's just
>>>> an example not a doctest" things and remove the ">>>" (since it doesn't
>>>> appear to provide any useful test coverage or anything).
>>> If possible, I'd like other possibilities be considered first before
>>> jumping this route. I think it would be nice to retain the ability to run
>>> also the matplotlib examples as (optional) doctests, to make sure also
>>> they execute correctly. Also, using two different markups in the
>>> documentation to work around a shortcoming of doctest is IMHO not very
>> How about a much simpler approach? Just pre-populate the globals dict
>> where doctest executes with an object called 'plt' that basically does
>> def noop(*a,**k): pass
>> class dummy():
>> def __getattr__(self,k): return noop
>> plt = dummy()
>> This would ensure that all calls to plt.anything() silently succeed in
>> the doctests. Granted, we're not testing matplotlib, but it has the
>> benefit of simplicity and of letting us keep consistent formatting,
>> and examples that *users* can still paste into their sessions where
>> plt refers to the real matplotlib.
> It's actually easier for users to paste the non-doctestable examples
> since they don't have the >>> markers and any stdout the examples
> produce as a byproduct.
I'm with Robert here. It's definitely easier as an example without the
>>>>. I also don't see the utility of being able to have the
matplotlib code as tests of anything. We're not testing matplotlib here
and any behavior that matplotlib relies on (and hence tests) should be
captured in a test for that behavior separate from matplotlib code.
Graduate Research Assistant
School of Meteorology
University of Oklahoma
More information about the Numpy-discussion