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
