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 -- John -- 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
