Re: [Tutor] A question about how python handles numbers larger than it's 32 bit limit

2008-09-23 Thread Kent Johnson
On Tue, Sep 23, 2008 at 11:16 AM, John Toliver <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> The book I have says when you anticipate that you will be working with
> numbers larger than what python can handle, you place an "L" after the
> number to signal python to treat it as a large number.

Your book is a little old, the "L" has not been required since Python 2.4.

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] A question about how python handles numbers larger than it's 32 bit limit

2008-09-23 Thread Steve Willoughby
On Tue, Sep 23, 2008 at 04:24:48PM +0100, Adam Bark wrote:
> 2008/9/23 John Toliver <[EMAIL PROTECTED]>
> 
> > Greetings,
> >
> > The book I have says when you anticipate that you will be working with
> > numbers larger than what python can handle, you place an "L" after the
> > number to signal python to treat it as a large number.  Does this
> > "treating" of the number only mean that Python won't try to represent
> > the number internally as a 32bit integer?  Python still appears to be
> > representing the number only with an L behind it so what is happening to
> > the number then.  Is the L behind the number telling python to handle
> > this large number in HEX instead which would fit into the 32 bit limit?
> >
> > thanks in advance,
> >
> > John T
> 
> 
> The L stands for long integer and means that it will usually use twice the
> space of a regular integer so in this case 64bits.

s/64bits/infinite/


Python is not C :)  In Python, long integers are unlimited
precision values, so you can accurately store a number like
32432471704327419865487605452750436198382489276811235713483294872389573259823495174875098750298475019874230984710985743980572840957432098578029107923471
if you want to.  They aren't handled as *fast* as regular native
integer values (which are implemented as the C "long int"
type internally in CPython, so they may be 32 bits or 
possibly(?) longer), but they are unlimited in size.

Python will automatically promote an integer to a long when
it gets too big, so you don't *have* to put the L on the
end or use long() to construct one explicitly, unless you
really want it to be long type from the beginning.


-- 
Steve Willoughby|  Using billion-dollar satellites
[EMAIL PROTECTED]   |  to hunt for Tupperware.
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


Re: [Tutor] A question about how python handles numbers larger than it's 32 bit limit

2008-09-23 Thread Adam Bark
2008/9/23 John Toliver <[EMAIL PROTECTED]>

> Greetings,
>
> The book I have says when you anticipate that you will be working with
> numbers larger than what python can handle, you place an "L" after the
> number to signal python to treat it as a large number.  Does this
> "treating" of the number only mean that Python won't try to represent
> the number internally as a 32bit integer?  Python still appears to be
> representing the number only with an L behind it so what is happening to
> the number then.  Is the L behind the number telling python to handle
> this large number in HEX instead which would fit into the 32 bit limit?
>
> thanks in advance,
>
> John T


The L stands for long integer and means that it will usually use twice the
space of a regular integer so in this case 64bits.
HTH
Adam.
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


[Tutor] A question about how python handles numbers larger than it's 32 bit limit

2008-09-23 Thread John Toliver
Greetings,

The book I have says when you anticipate that you will be working with
numbers larger than what python can handle, you place an "L" after the
number to signal python to treat it as a large number.  Does this
"treating" of the number only mean that Python won't try to represent
the number internally as a 32bit integer?  Python still appears to be
representing the number only with an L behind it so what is happening to
the number then.  Is the L behind the number telling python to handle
this large number in HEX instead which would fit into the 32 bit limit?

thanks in advance,

John T

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor