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


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

Re: len() on mutables vs. immutables

Started byTerry Reedy <tjreedy@udel.edu>
First post2012-10-18 14:29 -0400
Last post2012-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.


Contents

  Re: len() on mutables vs. immutables Terry Reedy <tjreedy@udel.edu> - 2012-10-18 14:29 -0400

#31671 — Re: len() on mutables vs. immutables

FromTerry Reedy <tjreedy@udel.edu>
Date2012-10-18 14:29 -0400
SubjectRe: 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

[toc] | [standalone]


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


csiph-web