Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #31679

RE: len() on mutables vs. immutables

From Nick Cash <nick.cash@npcinternational.com>
Subject RE: len() on mutables vs. immutables
Date 2012-10-18 18:28 +0000
References <50803B2C.6010900@gmail.com>
Newsgroups comp.lang.python
Message-ID <mailman.2469.1350587629.27098.python-list@python.org> (permalink)

Show all headers | View raw


> 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?

It appears that list has len() complexity of O(1)
source: http://wiki.python.org/moin/TimeComplexity
It may be worth mentioning that lists in Python are implemented using arrays instead of linked lists.

It's reasonable to assume that other built-in collection types would be similar, though I don't see anything explicitly saying so for bytearray.

-Nick Cash

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

RE: len() on mutables vs. immutables Nick Cash <nick.cash@npcinternational.com> - 2012-10-18 18:28 +0000

csiph-web