Logged In: YES 
user_id=341410

Integers are immutable.  That is, each integer with a
different value will be a different integer object (some
integers with the same value will also be different
objects).  In CPython, id(obj) is the memory location of
that object.

>>> a = 9876
>>> id(a)
9121340
>>> a += 1
>>> id(a)
8738760

It is assumed by the CPython runtime, based on significant
experience by CPython programmers, that if you are using a
large number of integers now, that you are probably going to
use a large number of integers in the future.

When an integer object is allocated, the object hangs around
for as long as it is needed, and when it is no longer
needed, it is placed on a list of allocated integer objects
which can be re-used, but which are never freed (the integer
freelist).  This allows Python to allocate blocks of
integers at a time when necessary (which speeds up
allocations), re-use unused integer objects (which removes
additional allocations in the majority of cases), and
removes the free() call (on many platforms, free() doesn't
work).

Integer freelists are not going away, and the behavior you
are experiencing is a result of integer freelists (though
the 163M rather than 123M memory used is a result of
FreeBSD's memory manager not being perfect).


As Tim Peters suggested, if you need to iterate through 10
million unique integers, do so via xrange, but don't save
them all.  If you can't think about how to do such a thing
in your application, you can ask users on the
comp.lang.python newsgroup, or via the
python-list@python.org mailing list, but remember to include
the code you are using now and a description of what you
want it to do.