What does Python fix?
pinard at iro.umontreal.ca
Mon Jan 21 18:27:48 CET 2002
> class listshare:
> def __init__(self, offset, alist):
> self._alist = alist
> self._offset = offset
> def __getitem__(self, index):
> return self._alist[index+offset]
> # etc, etc
> In which case, you can choose to use the referenced extension (where an
> object takes, I believe, three "words" -- a type-pointer, car, and cdr).
Plus, surely, a reference count, and the overhead required by the memory
allocator. Presumably, Python has its own allocator for small structures,
and the allocator overhead thus becomes insignificant.
> On the other hand, memory overhead for a very long Python list can be
> much lower (in the same sense, i.e., just for the structuring part)
> than an equivalently-long Lisp list, because the Python list is in
> fact implemented as a contiguous array of single pointers
I got myself into Python two years ago. Some time before, I worked on the
prototype of the GNU music project (which, by a strange set of circumstances,
became the marvelous Lilypond -- this would be a long story). The core
team was torn between a Lisp or Scheme implementation, C++, and others.
I finally wrote the thing in plain portable C. Knowing I would handle many
lists, I tried a representation similar to the above, feeling a bit deviant,
but convinced there were many virtues to this approach. So, it was part of
my pleasure, later discovering Python, to see that it made the same choices.
> I doubt that saving memory will be the dominating issue in any such
> "bigger application" -- issues of O(N) vs O(N log N) performance, and
> so on, would appear to be more likely to dominate, I think.
We should always have an idea on how resources are consumed by algorithms.
Best is to develop some background culture about how Python does things...
But yes, we agree!
François Pinard http://www.iro.umontreal.ca/~pinard
More information about the Python-list