On Mar 3, 2008, at 7:52 AM, David Roe wrote:
> I was not suggesting eliminating the ability to directly
> access .value from Cython. Rather, I see set_si() and get_si() as
> convenience functions so that if the only thing you're doing is
> converting back and forth between sage integer and
Fixing the ubiquitous accessing of .value would be far more work that it's
worth. The main functionality that I would like is a get_si() with bounds
checking. Given that, I think having a set_si as well is reasonable.
David
On Mon, Mar 3, 2008 at 9:36 AM, Joel B. Mohler <[EMAIL PROTECTED]>
wrote
On Monday 03 March 2008 08:42:53 am David Roe wrote:
> I think they should still exist, but should be cdef'd. This means I can
> interface between C longs and sage Integers without having to reach in and
> grab n.value, but one can't use them to make Integers mutable in Python. A
> function get_
I was not suggesting eliminating the ability to directly access .value from
Cython. Rather, I see set_si() and get_si() as convenience functions so
that if the only thing you're doing is converting back and forth between
sage integer and long, one can use object oriented notation (and so that you
On Mar 3, 5:42 am, "David Roe" <[EMAIL PROTECTED]> wrote:
> I think they should still exist, but should be cdef'd. This means I can
> interface between C longs and sage Integers without having to reach in and
> grab n.value, but one can't use them to make Integers mutable in Python. A
> function
I think they should still exist, but should be cdef'd. This means I can
interface between C longs and sage Integers without having to reach in and
grab n.value, but one can't use them to make Integers mutable in Python. A
function get_si() would also be useful if it did bounds checking so that I
