[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