On Tue, Jul 1, 2008 at 19:19, Ryan May <[EMAIL PROTECTED]> wrote: > Robert Kern wrote: >> On Tue, Jul 1, 2008 at 17:50, Fernando Perez <[EMAIL PROTECTED]> wrote: >>> On Tue, Jul 1, 2008 at 1:41 PM, Pauli Virtanen <[EMAIL PROTECTED]> 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 >>>> elegant. >>> 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.
To be clear, these aren't tests of the numpy code. The tests would be to make sure the examples still run. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
