On 4/12/07, David Roe <[EMAIL PROTECTED]> wrote:
>
> I just took a look at the Python 3000 PEP. A couple of points where
> things due to be phased out are commonly used in SAGE:
> -- raise ValueError, "That number shouldn't be zero" -- now illegal
> -- raise ValueError("That number shouldn't be zero") -- instead
>
> -- print "hello world" -- will become
> -- print("hello world") -- instead
>
> imports will be absolute by default.
>
> no more longs. Yay!
>
> Classic classes will be gone. I'm not sure what effect this will have,
> but I know that both classic and new classes exist in SAGE.
>
> dict.has_key method is disappearing.
>
> Defining __cmp__ will no longer make <, ==, > etc work: you have to define
> __richcmp__.
>
> Just some things to keep in mind while you're writing new code so that
> it's easier to make Python 3000 compliant.
> If you want to read the PEP it's at
> http://www.python.org/dev/peps/pep-3100/
> David
>
>
> On 4/12/07, William Stein <[EMAIL PROTECTED]> 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
> >
> > I think it's easier to read and more explicit.
> >
> > Comment 3:
> > Definitely __nonzero__ (or later __bool__) should be defined whenever
> > possible, so code like this behaves sensibly:
> > if x:
> > do blah
> >
> > 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...
> >
> > William
> >
> > > >
> >
>
--~--~---------~--~----~------------~-------~--~----~
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/
-~----------~----~----~----~------~----~------~--~---
