On Friday 21 July 2006 7:49 am, Nick Coghlan wrote:
Neal Becker wrote:
For a recent project I needed to select a container. There are plenty of
python data structures to choose from. It seems that information on
performance is missing (or not easy to find).
I think Python should
Hi Giovanni,
On Sun, Jul 23, 2006 at 03:30:50PM +0200, Giovanni Bajo wrote:
I'm not sure big-O tells the whole truth. For instance, do we want to allow
an implementation to use a hash table as underlying type for a list? It
would match big-O requirements, but would still be slower than a plain
Between the two of you, I think you have made the case that the language
specification is better to not include such details. As you both note,
it is difficult to capture the essence of what is desired from the
performance of the implementation. To tag on other version, what about
Big-O space
Armin Rigo wrote:
I think that O-wise the current CPython situation should be documented
as a minimal requirement for implementations of the language, with
just one exception: the well-documented don't rely on this hack in
2.4 to make repeated 'str += str' amortized linear, for which the 2.3
Jason Orendorff wrote:
On 7/21/06, Nick Coghlan [EMAIL PROTECTED] wrote:
However, I'm also struggling to think of a case other than list vs deque
where
the choice of a builtin or standard library data structure would be dictated
by big-O() concerns.
OK, but that doesn't mean the
Hi,
On Sat, Jul 22, 2006 at 12:33:45PM +1000, Nick Coghlan wrote:
Agreed, but there's more to doing that than just writing down the O() implied
by the current CPython implementation - it's up to Guido to decide which of
the constraints are part of the language definition, and which are
For a recent project I needed to select a container. There are plenty of
python data structures to choose from. It seems that information on
performance is missing (or not easy to find).
I think Python should include performance in the documentation of common
data structures to help users
Neal Becker wrote:
For a recent project I needed to select a container. There are plenty of
python data structures to choose from. It seems that information on
performance is missing (or not easy to find).
I think Python should include performance in the documentation of common
data
Nick Coghlan wrote:
Neal Becker wrote:
For a recent project I needed to select a container. There are plenty of
python data structures to choose from. It seems that information on
performance is missing (or not easy to find).
I think Python should include performance in the documentation
Neal Becker wrote:
On Friday 21 July 2006 7:49 am, Nick Coghlan wrote:
Neal Becker wrote:
For a recent project I needed to select a container. There are plenty of
python data structures to choose from. It seems that information on
performance is missing (or not easy to find).
I think
On 7/21/06, Nick Coghlan [EMAIL PROTECTED] wrote:
However, I'm also struggling to think of a case other than list vs deque where
the choice of a builtin or standard library data structure would be dictated
by big-O() concerns.
OK, but that doesn't mean the information is unimportant. +1 on
Jason Orendorff wrote:
However, I'm also struggling to think of a case other than list vs
deque where the choice of a builtin or standard library data
structure would be dictated by big-O() concerns.
OK, but that doesn't mean the information is unimportant. +1 on
making this something of a
On Jul 21, 2006, at 12:45 PM, Giovanni Bajo wrote:
Jason Orendorff wrote:
However, I'm also struggling to think of a case other than list vs
deque where the choice of a builtin or standard library data
structure would be dictated by big-O() concerns.
OK, but that doesn't mean the
Jason Orendorff wrote:
On 7/21/06, Nick Coghlan [EMAIL PROTECTED] wrote:
However, I'm also struggling to think of a case other than list vs
deque where
the choice of a builtin or standard library data structure would be
dictated
by big-O() concerns.
OK, but that doesn't mean the
14 matches
Mail list logo
