len() on mutables vs. immutables
demianbrecht at gmail.com
Fri Feb 8 02:09:31 CET 2013
So, it's taken me a little while longer than I figured to actually get the
time to dig around for the question that I had (added to the bottom of
this message for context).. Pretty mundane stuff, but I did the digging
(3.4.0a). Hopefully the results will help anyone else with the same
However, my research brought up a question (I'm assuming someone here can
If a memoryview is representing a non-continuguous block of memory (> 1
ndim), will len(obj) not return incorrect results? It seems to be
reporting the shape of the 0th dim at the moment.. Or is there something
that I'm missing altogether?
On 2012-10-18 5:26 PM, "Terry Reedy" <tjreedy at udel.edu> wrote:
>On 10/18/2012 2:42 PM, Demian Brecht wrote:
>> Awesome. Pretty much what I figured. Of course, I'll have to dig around
>> the source just to confirm this with my own eyes (more just curiosity
>> than anything),
>If you do, please followup with a report.
>Terry Jan Reedy
** Quote for context on a necro'd post **
I'm curious as to the implementation (I'd be happy to dig through the
source, just don't have the time right now). I've seen various
implementations across interpreters in the past (some which have been
rather shocking) and I'd like to get some insight into Python (well,
CPython at this point anyway).
When len() is called passing an immutable built-in type (such as a
string), I'd assume that the overhead in doing so is simply a function
call and there are no on-call calculations done. Is that correct?
I'd also assume that mutable built-in types (such as a bytearray) would
cache their size internally as a side effect of mutation operations. Is
that correct? If so, is it safe to assume that at least all built-in
types observe this behavior, or are there some that incur an O(n) cost
on every len() call?
Obviously this can't be controlled with custom types that implement
their own __len__, I'm only asking about Python's built-ins.
More information about the Python-list