[Bf-python] a remark concerning functions returning lists

[Willian Padovani Germano]

On Wed, 2003-06-18 at 18:09, Jacques Guignot wrote:
> OK, I'll modify my files accordingly.
> 
> The most important is that we have a standard, and keep as close to it 
> as possible.

Hi, Guignot

I just thought again (you know, when there's something wrong things keep
being thought in bg mode, then send your brain a msg when a conclusion
is reached ... creepy ; ) !)

I exagerated about the issue, though it still is better to tell the size
upon creation.

Thinking about it, in Python implementation it can be +- like this:
there's some struct like:

struct ListItems {
  struct ListItems *next;
  PyObject *data;
}

And when you create an empty list, it starts it with next = NULL (and
data = NULL, to tell it's the head of the list -- or uses some other
struct as the container of ListItems). Then each .append() allocates
space for a new ListItem, make the previous point to it and plugs the
data at the data field, letting the new next = NULL, again.

The advantage of telling the size upon creation then is only that N such
structs will be created in a row (considering PyTypes that can change
size, like lists), pointing to each other and with NULL data fields to
be filled with .insert() . That can help considerably against memory
fragmentation if the list is simply discarded later.  And it's also
faster.  The bigger the list, the more the lists, the more the gain, of
course.  Things like this also aren't set in stone in C: it's better to
do that way because it leaves room for the Python implementors to
optimize things, what they probably did.

--
Willian, wgermano at ig.com.br