I sympathise with David. We want volunteers to grab a file with a low level of documentation and document it, which is already a lot of work. But now it seems that the poor volunteer is expected to rewrite all the code to fit into as well! Surely this is a different level of activity and should not be a bar to getting documentation up to 100%.
So far I have just ognored that warning, since (as David) I did not know what to do about it. And Florent's reply makes me even less likely to do more.... John On 14 June 2010 23:46, Florent Hivert <florent.hiv...@univ-rouen.fr> wrote: > Hi, > > On Mon, Jun 14, 2010 at 03:13:53PM -0700, daveloeffler wrote: >> I've been doing some work adding doctests to some files that don't >> have them, and the coverage script kept telling me to put in a >> "TestSuite.run()" doctest. >> >> Can someone tell me how on earth I can get one of these to actually >> work? No matter what I do, if X is a parent object, >> "TestSuite(X).run()" always fails at the point where it creates an >> element of X and runs "_test_category" on it. > > 1 - Did you properly initialize category for your parent ? Looking at the code > from rings/ideal_monoid.py there isn't any category specified for the > constructor of Ideal_monoid_c. > > 2 - Did you specify in the parent how the element are represented ? There > isn't any definition of Element. > > 3 - If you don't want your object to get category stuff, you can simply > deactivate this test using the option skip=... > >> It seems to want >> elements of X to be instances of a "dynamic metaclass" created on the >> fly by the categories machinery. How is that supposed to work? How are >> rich, complicated objects (e.g. ideals in arbitrary rings -- I was >> working on rings/ideal_monoid.py) supposed to be represented by a >> class that's cooked up out of nowhere? > > I don't see the relevance of having rich objects in the discussion. > >> I looked for examples where TestSuite doctests already exist (and >> pass), but in all the ones I found either the element class didn't >> really do anything (e.g. the examples in sage/categories/examples) or >> the element class was a Cython extension type and thus exempt from >> this test. > > The idea (maybe it is not a good idea) of the doc in sage/categories/examples > is to provide minimal example. That why most of the things are trivial > here. Still the file sage/categories/examples/sets_cat.py demonstrate various > way of creating representing elements of your class: > - either by inheriting from an already written class > - or by wrapping element of an already build class > - or by having a facade parent that is a parent which deals with elements > whose parent is actually another parent (e.g: Prime v.s. Integer) > > Cheers, > > Florent > > -- > 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 > -- 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
