Hi, On Wed, Jul 27, 2011 at 12:25 PM, Mark Wiebe <mwwi...@gmail.com> wrote: > On Wed, Jul 27, 2011 at 1:01 PM, Matthew Brett <matthew.br...@gmail.com> > wrote: >> >> Hi, >> >> On Wed, Jul 27, 2011 at 6:54 PM, Mark Wiebe <mwwi...@gmail.com> wrote: >> > This was the most consistent way to deal with the parameterized dtype in >> > the >> > repr, making it more future-proof at the same time. It was producing >> > reprs >> > like "array(['2011-01-01'], dtype=datetime64[D])", which is clearly >> > wrong, >> > and putting quotes around it makes it work in general for all possible >> > dtypes, present and future. >> >> I don't know about you, but I find maintaining doctests across >> versions changes rather tricky. For our projects, doctests are >> important as part of the automated tests. At the moment this means >> that many doctests will break between 1.5.1 and 2.0. What do you >> think the best way round this problem? > > I'm not sure what the best approach is. I think the primary use of doctests > should be to validate that the documentation matches the implementation, and > anything confirming aspects of a software system should be regular tests. > In NumPy, there are platform-dependent differences in 32 vs 64 bit and big > vs little endian, so the part of the system that changed already couldn't be > relied on consistently. I prefer systems where the code output in the > documentation is generated as part of the documentation build process > instead of being included in the documentation source files.
Would it be fair to summarize your reply as 'just deal with it'? See you, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
