Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #31679
| 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) |
> 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
RE: len() on mutables vs. immutables Nick Cash <nick.cash@npcinternational.com> - 2012-10-18 18:28 +0000
csiph-web