Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #31671 > unrolled thread
| Started by | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| First post | 2012-10-18 14:29 -0400 |
| Last post | 2012-10-18 14:29 -0400 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: len() on mutables vs. immutables Terry Reedy <tjreedy@udel.edu> - 2012-10-18 14:29 -0400
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2012-10-18 14:29 -0400 |
| Subject | Re: len() on mutables vs. immutables |
| Message-ID | <mailman.2460.1350584990.27098.python-list@python.org> |
On 10/18/2012 1:23 PM, Demian Brecht wrote: > 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? See below. > 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 Or the length could be the difference of two pointers -- address of the first empty slot minus address of first item. > that correct? If so, is it safe to assume that at least all built-in > types observe this behavior, str, bytes, bytearrays, arrays, sets, frozensets, dicts, dictviews, and ranges should all return len in O(1) time. That includes the possibility of a subtraction as indicated above. -- Terry Jan Reedy
Back to top | Article view | comp.lang.python
csiph-web