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?
> - Do we want to have the .test object appear for every sage object?
> i.e. 1.test (William was not that happy about this)
>
> What are some objects other than parents that would be making use of this?
I already have at least Categories and cartan types. There certainly
will be further objects which are in categories that do not derive
from Sets (at SD15, I discussed the design of some of those around
chain complexes). In general any Sage object which is not an element
is a good candidate (elements might not need that since one could
expect that they would be tested via their parents).
> Other concerns:
>
> - This adds yet another layer of complexity. The user has to learn
> that to implement foo.test.associativity, he should actually add a
> method _test_associativity in the class of foo (or some
> superclass). We want our users and developers to use and write lots
> of tests, so we have to keep it simple, s*d.
>
> No, the user just needs to write some_elements(). Or, if they wanted more
> control over how associativity was tested, they could write
> _test_associativity
> (), but they wouldn't need to.
Sorry, I meant: if a user/developer wants to add a new test_bla
functionality, he has to find out that he should implement _test_bla
in ...
> - I just don't have the time to implement this *now* (I probably
> could do the renaming .check -> ._check and .test_bla to
> ._test_bla). Sorry, I have been advertising this feature for more
> than 3 months, and it would have been easier to reserve time for
> this earlier in the process ...
>
> Yeah, I know how that feels. Sorry to contribute to that in the category
> review. I'm working on it now.
Thanks!
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
-~----------~----~----~----~------~----~------~--~---
