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

Steve Willoughby steve at alchemy.com
Tue Sep 23 17:33:44 CEST 2008


On Tue, Sep 23, 2008 at 04:24:48PM +0100, Adam Bark wrote:
> 2008/9/23 John Toliver <john.toliver at gmail.com>
> 
> > 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
steve at alchemy.com   |  to hunt for Tupperware.


More information about the Tutor mailing list