William, I think TESTS:: would be a good idea! Having an optional part TESTS:: where one can put more or less any Sage code; if TESTS:: is present, EXAMPLES:: is ignored, and otherwise EXAMPLES:: play the role of TESTS::
Indeed, without this it is impossible to really test, say, a function that produces a matrix that is only known up to (unknown) permutations of rows and columns. An example of a test that is basically not possible to make consistently, is values() sage/groups/class_function.py (this function basically returns such a matrix, namely a character table of a group, for which the order of conj. classes etc is a priori not known) Dima On Jan 29, 2:09 pm, William Stein <wst...@gmail.com> wrote: > On Thu, Jan 28, 2010 at 10:06 PM, John H Palmieri > > > > > > <jhpalmier...@gmail.com> wrote: > > On Jan 28, 9:59 pm, Dima Pasechnik <dimp...@gmail.com> wrote: > >> as discussed recently here in connection with GAP interface, the > >> following looks like an obvious deficiency of docstrings testing: a > >> computation returns a list in some unpredictable order, and docstrings > >> are in another order, even though the corresponding sets are the same. > > >> Just sorting the list in Sage does not work, as the object in question > >> has a state maintained by an external program (e.g. GAP), and messing > >> up this order is no fun at all. > >> (well, yes, one can think of maintaining the permutation used for the > >> sorting, etc etc, but this looks like an unnecessary kludge) > > >> It seems to me that the right way to deal with this is to extend the > >> capabilities of the testing scheme so that it is able to handle sets, > >> not only lists. > > > Maybe you can write doctests in one of these forms > > > sage: set([output from function...]) == set([what the output is > > supposed to be]) > > True > > > (or use Set instead of set?) > > > sage: (some known element) in [output from function] > > True > > > sage: convert output to string and do some string comparisons on it > > +1 to John's suggestion to rewrite your tests so that the lists are > sorted in a sensible way. There are many ways to do so as he pointed > out. If we can avoid it, we shouldn't change the Python doctest > framework any more than we already have (which is very minimal). > > We could add a function to Sage for testing purposes, such as: > > sage: strsort(v) > > which would takes it input (any iterable), convert all entries to > strings, then sort, then output the result as a list. Then your > doctests would display that output. > > It's good to keep in mind that doctests are meant to be viewed by > people, so tests like the above that maybe aren't so human readable > should go in the > > TESTS:: > > section instead of the EXAMPLES:: section. > > -- William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
