This helped clarify, thanks. I also went through PEP 3118 in detail (as I
should have in the first place) which also helped.
Thanks,
Demian Brecht
http://demianbrecht.github.com
On 2013-02-08 6:50 AM, "Oscar Benjamin" wrote:
>This is in keeping with the way that numpy.ndarrays work. Essential
On 8 February 2013 06:24, Demian Brecht wrote:
> On 2013-02-07 8:30 PM, "Terry Reedy" wrote:
>
> If a memoryview (3+) is representing a non-continuguous block of memory (>
> 1
> ndim), will len(obj) not return incorrect results? It seems to be
> reporting the shape of the 0th dim at the moment..
On 2013-02-07 8:30 PM, "Terry Reedy" wrote:
>So you may assume
I've been bitten far too many times by incorrect assumptions about
implementations that ended up actually doing something quite silly. Having
said that, I felt fairly safe in making that assumption with Python, but
figured I'd write s
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
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 a
17 matches
Mail list logo
