The REALLY bad thing about Python lists ..

[Andrew Dalke]

Courageous wrote:
>I'm curious, looking at this, why we're not able to access
>the initial sizes and growth rates directly? While such
>needs are rare, and therefore shouldn't be added syntatic
>weight for the everyday user, I'd think there would be
>some benefit in allowing the complexity fiends some level
>of access with relatively little cost

I've never needed in the two years I've been using Python.
In the three years I've been reading the newsgroup, it's never
come up before.  There is a relevant post from Guido I recall,
related to modifications to sort allowing callbacks:

http://www.deja.com/[ST_rn=ps]/getdoc.xp?AN=342411242&fmt=text

And I quote nearly fully "Blechh!  Creeping featurism!"

Besides, to do it well and in the context of multiple threads (where
each thread might want to tweak the parameters) means you need either
a list generator of some sort.

If you really need to modify how list resizing is done, take Moshe's
advice and make a new class which implements a list the way you want
it to be, as in:

class ScalableList:
  def __init_(self, data):
    self.data = []
    self.data[:] = data[:]
    self._size = len(self.data)
    self.data.extend([None] * 10)  # initally pad 10 extra elements
  def __len__(self):
    return self._size
  def append(self, item):
    if self._size == len(self.data):
       self.data.extend([None] * self._size)  # use your own scaling
    self.data[self._size] = item
  def __getitem__(self, i):
    if i < 0:
       i = i + self._size
       if i < 0:
          raise IndexError, i-self._size
    elif i >= self._size:
       raise IndexError, i
    return self.data[i]
  ...

Not very hard to implement, and you can tune it whichever way.  Yes,
there's the method call overhead, but if the n**2 performance is bugging
you, the call overhead is only linear.

                    Andrew
                    dalke at acm.org