Hi David, > > In order to sanitize the behavior of objects, parents and elements in sage, > > I'm about to add some tests to the framework. I think they are all > > reasonable > > but I may be asking to much. Please comment about the following: > > > > 1 - Any SageObject must have an equality methods such that > > self == self and self != None > > > > I don't think this should be true for an arbitrary SageObject. There are > some (eg subclasses of sage.factory.UniqueFactory) that are mainly used > either internally or as object constructors. I don't think we need to > support GF == GF for example. > > Requiring it for Parents and Elements seems completely reasonable on the > other hand. Perhaps CategoryObjects as well.
Ok This is easy to change... [...] > > 3 - .zero() and .one() must never be mutable. I'd like to enforce this by > > computing .__hash__(). Here I see two possibilities: > > * decide that for any monoid M, if M.one() implement __hash__ it > > must > > returns an int (not an Integer) and not raise an exception like in > > sage: m = matrix([1]).__hash__() > > ... > > TypeError: mutable matrices are unhashable > > > > I have no problem with requiring an int return value, though I'm not sure > how compliant the current sage library is with this condition. The best way to know is to check (in progress). I'm expecting to catch some bugs with it. I'll see how hard it is to fix the lib accordingly. The framework allows to make case by case exception. Anyway, it's certainly good to know. > I don't like the requirement that __hash__ never raise an error: we want to > allow mutable matrices. Of course I'm not forgetting mutable matrices. Let me restate. Please choose between (or suggest something else): Strong requirement: For any Monoid. __hash__ *must* be implemented and it don't raise an error for .one() (Idem for CommutativeMonoids and zero()) Weak requirement: For any monoid M, if M.one() implement __hash__ it must returns an int. > This seems like the better option. Though some have raised objections to > the idea of zero() and one() returning immutable elements, it did seem to be > the consensus in that thread. So I understand that you'll go for strong requirement. I'm sorry for not making myself clear it the first mail. I'm not accustomed in writing computer-law statement like SEP (Sage Enhancement Proposal :-) Cheers, Florent -- 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
