On 8 February 2013 06:24, Demian Brecht demianbre...@gmail.com wrote:
On 2013-02-07 8:30 PM, Terry Reedy tjre...@udel.edu 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
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 oscar.j.benja...@gmail.com wrote:
This is in keeping with the way that
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.
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
On 2013-02-07 8:30 PM, Terry Reedy tjre...@udel.edu 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
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
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
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
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
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
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'd
On Thu, Oct 18, 2012 at 1:18 PM, Prasad, Ramit
ramit.pra...@jpmorgan.com 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
On Thu, Oct 18, 2012 at 8:42 PM, Demian Brecht demianbre...@gmail.com 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
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
ramit.pra...@jpmorgan.com wrote:
Why does pointer arithmetic work for dicts? I would think the position
of a value would
On Thu, Oct 18, 2012 at 12:43 PM, Daniel Urban urban.d...@gmail.com 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.,
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 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
--
17 matches
Mail list logo
