<[EMAIL PROTECTED]> wrote: > Sorry for responding to my own post. > > I think I understand the original statement now. What you are really > saying is that there is a pool of Python float objects (which can, at > different times, wrap different values) which can grow but never > decrease in size. So the memory held by this pool is dictated by the > maximum number of floats that have ever been simultaneously active > (accessible). > > The same goes for integers. All the more reason to avoid range(.) and > use xrange(.).
Uh? The integers produced as you loop over xrange will be just immortal as those that get into the list built by range, so why is int immortality any reason to use one over the other? If you know you're probably not going to loop over ALL the range or xrange, sure, but that's relatively rare -- and, when it does occur, xrange is seriously preferable: helen:~ alex$ python -mtimeit 'for x in range(100): pass' 100000 loops, best of 3: 15.9 usec per loop helen:~ alex$ python -mtimeit 'for x in xrange(100): pass' 100000 loops, best of 3: 12.2 usec per loop helen:~ alex$ python -mtimeit 'for x in range(100): break' 100000 loops, best of 3: 7.57 usec per loop helen:~ alex$ python -mtimeit 'for x in xrange(100): break' 1000000 loops, best of 3: 1.5 usec per loop The immediate break only halves the time requirements of the range-based loop, but it slashes by 8 times those of the xrange-based one -- now THAT is big enough to matter, as opposed to the 20% or so difference in overhead when you're always looping all the way, which is unlikely to make an important difference in overall application speed. Alex -- http://mail.python.org/mailman/listinfo/python-list
