Steven D'Aprano <[EMAIL PROTECTED]> writes:
> I'm discussing memory allocation techniques with somebody, and I'm trying to
> find a quote from -- I think -- Tim Peters where he discusses the way Python
> allocates memory when you append to lists. In basic terms, he says that every
> time you try t
Fredrik Lundh wrote:
I = iter(L)
I
>
>
>
len(I)
>
> 3
[...]
> (it's probably not a good idea to rely on this behaviour...)
I believe this has been classified as a bug in Python 2.4, which
will be undone in Python 2.5.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/pyt
Fredrik Lundh wrote:
> Alex Martelli wrote:
>
>> (there is no common Python type on which you can both call
>> len(...) AND the .next() method, for example -- a combination
>> which really makes no sense).
>
L = [1, 2, 3]
len(L)
> 3
I = iter(L)
I
>
>
> (it's probably not a g
Alex Martelli wrote:
> (there is no common Python type on which you can both call
> len(...) AND the .next() method, for example -- a combination
> which really makes no sense).
>>> L = [1, 2, 3]
>>> len(L)
3
>>> I = iter(L)
>>> I
>>> len(I)
3
>>> I.next()
1
>>> len(I)
2
>>> I.next()
2
>>> len(I
Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
> > s = [k for k in iterable]
> >
> > if I know beforehand how many items iterable would possibly yield, would
> > a construct like this be faster and "use" less memory?
> >
> > s = [0] * len(iterable)
> > for i in xrange(len(iterable)):
> >
On Tue, 11 Oct 2005 11:22:39 +0200, Lasse Vågsæther Karlsen wrote:
> This begs a different question along the same lines.
Er, no it doesn't. "Begs the question" does _not_ mean "asks the question"
or "suggests the question". It means "assumes the truth of that which
needs to be proven".
http://e
Lasse Vågsæther Karlsen wrote:
> If I have a generator or other iterable producing a vast number of
> items, and use it like this:
>
> s = [k for k in iterable]
>
> if I know beforehand how many items iterable would possibly yield, would
> a construct like this be faster and "use" less memory?
>
Sybren Stuvel wrote:
> Steven D'Aprano enlightened us with:
>
>>he says that every time you try to append to a list that is already
>>full, Python doubles the size of the list. This wastes no more than
> If, on the other hand, you double the memory every time you run out,
> you have to copy much
Steven D'Aprano enlightened us with:
> he says that every time you try to append to a list that is already
> full, Python doubles the size of the list. This wastes no more than
> 50% of the memory needed for that list, but has various advantages
> -- and I'm damned if I can remember exactly what th
While there may be a discussion somewhere in the archives,
the comments in listobject.c are enlightening too.
/* Ensure ob_item has room for at least newsize elements, and set
* ob_size to newsize. If newsize > ob_size on entry, the content
* of the new slots at exit is undefined heap trash; it
http://mail.python.org/pipermail/python-list/2003-December/198141.html
wherein Tim gently corrects my brash guess that Python lists are
pointer-linked.
The example's linearly-constructed list is allocated by doubling storage,
copying & freeing (cf realloc).
The result that the process virtual memo
Can somebody help me please? I've spent a fruitless
hour googling with no luck.
I'm discussing memory allocation techniques with
somebody, and I'm trying to find a quote from -- I
think -- Tim Peters where he discusses the way Python
allocates memory when you append to lists. In basic
terms,
12 matches
Mail list logo
