On Friday 13 April 2007 02:03, William Stein wrote: > On 4/12/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Hi there, > > > many classes in SAGE implement and test for is_zero. I think these > > > methods should be replaced with __nonzero__ methods, as this is the > > > standard way of > > > doing such a test in Python. For example, int doesn't have a > > > is_zero(), such > > > that one would have to test for a type (of a return value) first. > > > > +1, and document this in structure.element. > > Comment 1: > My first comment is that __nonzero__ is going to be removed from Python > in Python 3000, so you should read the thread here about it being removed: > > http://mail.python.org/pipermail/python-3000/2006-November/004524.html > > (Python 3000 being the Python in SAGE is probably not as far off as you > might think... I realized this at the scipy talk that Guido gave on > Python 3000.) > > So in the future, __nonzero__ will be replaced by __bool__; currently > the point of __nonzero__ is to implement bool(x) for x an object. > > Comment 2: > One of the most important and used functions in MAGMA is "IsZero". > MAGMA doesn't have an "IsNonzero". > Likewise, in sage it appears in search_src('is_zero') over 200 times. > This all suggests that for mathematics programming, conceptually > "is zero" is the function one wants, and that moreover in writing > code it is very natural to use a function called "is zero". Getting > rid of is_zero and replacing it by __nonzero__ is thus not natural, > since it's the opposite. I really don't like code like this: > > if my_complicated_number: > do blah > > when my_complicated_number is some sort of complicated mathematical object. > I much prefer > > if not my_complicated_number.is_zero(): > do blah > > or even > > if my_complicated_number.is_nonzero(): > do blah
My main problem is that you cannot call int(0).is_zero() which happens quite often in my code. > Conclusions: > (1) Do not eliminate the is_zero method. I.e., it should still be > possible to write > x.is_zero() for x an element. > (2) Do implement __nonzero__, and redefine is_zero in the base to be > def is_zero(self): > return self.__nonzero__() > (3) Make sure no derived classes define is_zero; they should instead > always define __nonzero__. > (4) I wish there were code to certify that derived classes don't > define things they > shouldn't define... Sounds good (as it still allows me to write "if my_complicated_number"). I will send you a patch. Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [EMAIL PROTECTED] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
