On 2/7/2013 8:09 PM, Demian Brecht wrote:
http://demianbrecht.github.com/posts/2013/02/07/understanding-len/
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 do
So, it's taken me a little while longer than I figured to actually get the
time to dig around for the question that I had (added to the bottom of
this message for context).. Pretty mundane stuff, but I did the digging
(3.4.0a). Hopefully the results will help anyone else with the same
questions.
h
On 10/18/2012 2:42 PM, Demian Brecht wrote:
Awesome. Pretty much what I figured. Of course, I'll have to dig around
the source just to confirm this with my own eyes (more just curiosity
than anything),
If you do, please followup with a report.
--
Terry Jan Reedy
--
http://mail.python.org/mai
On 10/18/2012 3:18 PM, Prasad, Ramit wrote:
Terry Reedy wrote:
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.
On Thu, Oct 18, 2012 at 12:43 PM, Daniel Urban wrote:
> The source is usually in Objects/*object.c (e.g., the source for list
> is in Objects/listobject.c, dict is in dictobject.c and so on). The
> implementation of __len__ is usually in a method called
> whatever_length (e.g., dict.__len__ is cal
Ian Kelly wrote:
> Sent: Thursday, October 18, 2012 2:39 PM
> To: Python
> Subject: Re: len() on mutables vs. immutables
>
> On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit
> wrote:
> > Why does pointer arithmetic work for dicts? I would think the position
> > of
On Thu, Oct 18, 2012 at 8:42 PM, Demian Brecht wrote:
>> 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.
>
> Awesome. Pretty much what I figured. Of course, I
On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit
wrote:
> Why does pointer arithmetic work for dicts? I would think the position
> of a value would be based on the hash of the key and thus "random" for
> the context of this conversation.
It doesn't. len() on CPython dicts is O(1) because the dict
Terry Reedy wrote:
> 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'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 p
On 10/18/2012 11:29 AM, Terry Reedy wrote:> Or the length could be the
difference of two pointers -- address of the
> first empty slot minus address of first item.
That would assume contiguous blocks of memory, which I would find to be
rather dangerous (of an assumption that is) in most dynamic
On 10/18/2012 11:28 AM, Nick Cash wrote:
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 colle
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 buil
13 matches
Mail list logo
