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
-~----------~----~----~----~------~----~------~--~---

Reply via email to