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


Groups > comp.lang.python > #31667 > unrolled thread

len() on mutables vs. immutables

Started byDemian Brecht <demianbrecht@gmail.com>
First post2012-10-18 10:23 -0700
Last post2012-10-18 10:23 -0700
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python


Contents

  len() on mutables vs. immutables Demian Brecht <demianbrecht@gmail.com> - 2012-10-18 10:23 -0700

#31667 — len() on mutables vs. immutables

FromDemian Brecht <demianbrecht@gmail.com>
Date2012-10-18 10:23 -0700
Subjectlen() on mutables vs. immutables
Message-ID<mailman.2457.1350581045.27098.python-list@python.org>
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.

Thanks,
Demian
@demianbrecht
http://demianbrecht.github.com

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web