On Wed, Jun 24, 2009 at 06:33:42PM +0200, William Stein wrote:
>
> On Wed, Jun 24, 2009 at 6:30 PM, Robert
> Bradshaw<rober...@math.washington.edu> wrote:
> >
> > On Jun 24, 2009, at 12:52 AM, William Stein wrote:
> >
> >>>>>>
> >>>>>> But, err, guys, are you telling *me* that you want an
> >>>>>> attribute here
> >>>>>> instead of a method? Or should this be:
> >
> > One new attribute in tab completion is fine. A dozen, not so much. I
> > still like the approach below better though.
> >
> >>>> I am still opposed to adding a non-underscore method to SageObject.
> >>>>
> >>>> I did like Robert Bradshaw's other suggestion to do something
> >>>> like the
> >>>> following.
> >>>>
> >>>> sage: Test(foo).associativity()
> >>>>
> >>>> sage: Test?
> >>>> [[descript testing framework]]
> >>>>
> >>>> I.e., just create a Sage class "Test", which gives access to the
> >>>> test
> >>>> functionality, documents it, can even do something useful on objects
> >>>> foo that aren't necessarily SageObjects at all, etc.
> >>>>
> >>>> Test(obj) returns something that provides all kinds of functionality
> >>>> and methods for testing said object. This can call certain _
> >>>> methods
> >>>> on obj.
> >>>
> >>> That would be fine for me too. The only thing I really care for is
> >>> for
> >>> the actual test methods (._test...) to be attached to foo, and
> >>> derived
> >>> from its classes.
> >>>
> >>> What syntax would you suggest to run all tests?
> >>>
> >>> One thing I am not very keen on is that to get the list of available
> >>> tests, one need to do:
> >>>
> >>> sage: t = Test(foo)
> >>> sage: t.ass<tab>
> >>>
> >>> But I guess I can live with that (in practice, I myself will be
> >>> using t._test_ass<tab>)
> >
> > That also seems to read a bit funny. Why not a global tester object,
> > so one could do.
> >
> > tester.test_associativity(foo)
> >
> > (OK, the test there is a bit redundant, maybe test.associativity(foo)
> > or tester.is_associative(foo)")
>
> I also like the idea of a global tester object. Though, an advantage of
> t = Test(foo) is that it is way more flexible. I.e.,
>
> sage: t = Tester(some_arithmetic_thing)
> sage: t.<tab> ---> various arithmetic type tests
> sage: type(t)
> <some sort of "arithmetic tester">
>
> sage: t = Tester(a_web_server)
> sage: t.<tab> ---> various network type tests
> sage: type(t)
> <some sort of "web framework tester">
>
> sage: t = Tester(an_element)
> sage: type(t)
> <some sort of "element tester">
Yes, that's *precisely* the point.
> Of course the tester objects could all fit into a class hierarchy eventually.
Which would make yet another duplicate of the class hierarchy.
The way it's implemented (having the _test_bla in the same class as
the object) avoids this, while keeping the tests close to the code. A
category or abstract class typically have things like:
@abstract_method
def blah(self)
"""
...
"""
def _test_blah(...):
"""
Runs generic tests on blah
"""
Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nthi...@users.sf.net>
http://Nicolas.Thiery.name/
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
