On Wed, Jun 24, 2009 at 9:18 AM, Nicolas M. Thiery<nicolas.thi...@u-psud.fr> wrote: > > On Wed, Jun 24, 2009 at 08:49:20AM +0200, William Stein wrote: >> >> On Wed, Jun 24, 2009 at 8:33 AM, Nicolas M. >> Thiery<nicolas.thi...@u-psud.fr> wrote: >> > >> > On Wed, Jun 24, 2009 at 12:01:58AM -0400, David Roe wrote: >> >> On Tue, Jun 23, 2009 at 7:08 PM, Nicolas M. Thiery >> >> <nicolas.thi...@u-psud.fr> wrote: >> > >> >> On Tue, Jun 23, 2009 at 10:29:34AM +0200, Franco Saliola wrote: >> >> > > I'm also in favor of _test_X to avoid cluttering up the tab >> >> > > completion. Another option to increase visibility would be to >> >> have a >> >> > > test object, e.g. >> >> > > >> >> > > sage: foo.test.associativity() >> >> > > True >> >> > >> >> > +1. I think it merges the two concerns together nicely (visibility >> >> and >> >> > avoiding clutter). >> >> >> >> Thanks for the feedback! I agree that the syntax looks good. >> >> >> >> But, err, guys, are you telling *me* that you want an attribute here >> >> instead of a method? Or should this be: >> >> >> >> I'm fine with it as a lazy attribute. >> > >> > Taking a good note of that :-) >> > >> >> >> >> foo.test().associativity? >> >> >> >> I also like the clean aspect of separating the test object. But one of >> >> the main point of doing this would be to stick more closely to the >> >> testunit framework. But then that would call for: >> >> >> >> foo.test().test_associativity() >> >> >> >> which is not that nice anymore. >> >> >> >> Some other questions: >> >> >> >> - what syntax do you want to run all tests? >> >> >> >> foo.check() >> >> >> >> foo.test().run() >> >> >> >> foo.test() / foo.test.associativity() >> >> >> >> >> >> foo.test(). The __call__ method on the test object runs the tests (would >> >> this >> >> work with a lazy attribute? Yes, right?) >> > >> > No problem. Well, I actually would just use a property rather than a >> > lazy_attribute, since there is no reason to cache the test object. >> > >> > Do we have a consensus on this? >> >> 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>)
Yeah -- it seems that we have a consensus! - William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
