On Tue, Jun 15, 2010 at 08:52:04AM +0100, John Cremona wrote:
> 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 ignored 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....
Ok, let me expand just a bit on Florent's reply.
Quick and dirty option: you can still use the good old idiom to
silence sage -coverage:
sage: loads(dumps(F)) == F
However, I do not recommend this, as we want to use the occasion of
doc-testing everything to point out the parents that have not yet been
categorified, and/or do not pass all category tests.
Intermediate option: use the ``skip`` option that Florent advertise to
explicitly skip the failing tests:
sage: I = IdealMonoid(QQ[x])
sage: TestSuite(I).run(skip = ["_test_an_element", "_test_associativity",
"_test_elements", "_test_elements_eq", "_test_one", "_test_prod",
"_test_some_elements", "_test_category", "_test_pickling"])
and create a ticket "Categories for ideal monoids" mentioning the
above, with a pointer from:
http://trac.sagemath.org/sage_trac/wiki/CategoriesRoadMap
(look for "Make all parents inherit from categories, and use
TestSuite?(...).run()")
Or you can do the right thing as David started to: use the occasion to
fix IdealMonoid to properly use categories. See e.g. #8576 for an
example.
> That's very precisely what I'm asking: how should I be doing this?
If I may indulge myself: we definitely understand your frustration:
Sage documentation on how to properly implement parents is still
insufficient. However, we already did spend an *enormous* amount of
time documenting the category code. All of this to say that, with a
little "please" Florent would have right away been willing to invest
the time for a longer answer :-)
> I tried putting in
> class IdealMonoid_c:
> ...
> Element = ideal.Ideal_generic
> but that doesn't seem to do suffice: now IdealMonoid_c.element_class
> is a dynamic subclass of Ideal_generic, but the classes of elements
> of an IdealMonoid inherit directly from Ideal_generic; how do I make
> them inherit from this magic dynamic class?
> I've uploaded what I've got so far at trac #9242. Any suggestions on
> how I get the last remaining test to pass would be very welcome.
Here you are running in an extra difficulty, for which there is not
yet a standardized idiom: this parent has elements in several classes.
There are two/three places in Sage's code where this occurs, and this
is handled by hand, using __make_element_class__.
Probably the Ideal function could do something like:
Ideal_pid_with_category = IdealMonoid().__make_element_class__(Ideal_pid)
and use that class instead of Ideal_pid directly.
It's a bit inconvenient; I very much hope that once we will have
gathered more experience and use cases, we will find a slick idiom
which will hide this technical detail.
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--
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
