Tim Peters wrote:
You seem to be ignoring possiblities for sharing across lists, and
such sharing is natural in many graph algorithms.
No doubt cons cells are a useful construct. I think Martin Blais
(and others) advocated a plain list container type, only implemented
as a linked list, instead
Phillip J. Eby wrote:
Since I routinely use 2-item tuples (twoples?)
I've been using pairs to describe that datatype. Not sure
how common it is in English, but in German, Zweitupel
is often called Paar.
Regards,
Martin
___
Python-Dev mailing list
On Dec 28, 2005, at 2:57 AM, Martin v. Löwis wrote:
Phillip J. Eby wrote:
Since I routinely use 2-item tuples (twoples?)
I've been using pairs to describe that datatype. Not sure
how common it is in English, but in German, Zweitupel
is often called Paar.
I use 'pair', too, admittedly by
Hi Christian,
On Mon, Dec 26, 2005 at 01:38:37PM +0100, Christian Tismer wrote:
I don't think your code has to decide about this. The power lies
in the fact that you don't specify that, but just use the list
in a different way. We do this in the PyPy implementation;
right now it is true that
Dear Armin,
You are mentioning confusingly many levels of PyPy for this argument.
This is true, I didn't want to care.
This is not directly related to static analysis nor to the JIT. The
point is just that while a Python program runs, the implementation can
decide to start using a
Martin Blais wrote:
On 12/25/05, Christian Tismer [EMAIL PROTECTED] wrote:
[is auto-dequeue too much magic?]
IMO it's a little bit too much magic. Plus, if you pass these
instances around e.g. between libraries, how could you determine with
certainty the usage patterns without analysing the
On 12/25/05, Josiah Carlson [EMAIL PROTECTED] wrote:
Tim Peters [EMAIL PROTECTED] wrote:
Like Phillip Eby, I use 2-tuples for this when I feel the need
(usually during a backtracking graph search, to keep track of paths
back to the root in a space-efficient way), and am happy with that.
On Dec 26, 2005, at 11:07 AM, Martin Blais wrote:
Then there's the whole Python list with append() and pop(). It
takes a
method resolution and function call, but at least in Python 2.3,
it is a
hair faster...
Josiah, that's beside the point, because it is not space-efficient,
the
[restoring context and attributions lost in the original]
[Tim Peters]
Like Phillip Eby, I use 2-tuples for this when I feel the need
(usually during a backtracking graph search, to keep track of paths
back to the root in a space-efficient way), and am happy with that.
[Josiah Carlson]
Then
[restoring context and attributions lost in the original]
[Tim Peters]
Like Phillip Eby, I use 2-tuples for this when I feel the need
(usually during a backtracking graph search, to keep track of paths
back to the root in a space-efficient way), and am happy with that.
[Josiah
...
[Tim Peters]
I'm sure he did ;-) Consider a very simple graph, a skinny tree
rooted at `A` that branches once at the end, represented by a dict
of adjacency lists:
[Josiah Carlson]
Are you sure?
Of what?
...
But one doesn't _need_ to use flat lists.
Of course not. You didn't
At 11:04 AM 12/26/2005 -0800, Josiah Carlson wrote:
Not necessarily so as I have pointed out above. You said yourself;
practicality beats purity. While using cons cells are pure, as us using
only flat lists are pure, flat lists are practically smaller than cons
cells in certain cases (by a
Hi all,
not addressing anybody directly here,
but this thread is about my dequeue question.
It would just be nice if you could use the original thread
topic or a different one to discuss the original question.
--
Christian Tismer :^) mailto:[EMAIL PROTECTED]
tismerysoft GmbH
Guido van Rossum wrote:
Python's philosophy about (built-in) data types, inherited from ABC,
is to offer a few powerful clearly distinct choices rather than lots
of alternatives with overlapping usages. This reduces the time it
takes to choose a data type and reduces the risk of picking the
On 12/25/05, Christian Tismer [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
Python's philosophy about (built-in) data types, inherited from ABC,
is to offer a few powerful clearly distinct choices rather than lots
of alternatives with overlapping usages. This reduces the time it
takes
At 09:10 PM 12/25/2005 -0500, Martin Blais wrote:
I still haven't had time to cook a proper reply to Guido, but one
thing I see is that many ppl on the list seem to think that because
there aren't many use cases (that they can see), therefore there isn't
much use for a list collection type. I
On Sun, Dec 25, 2005, Martin Blais wrote:
I still haven't had time to cook a proper reply to Guido, but one
thing I see is that many ppl on the list seem to think that because
there aren't many use cases (that they can see), therefore there isn't
much use for a list collection type.
Please
[Martin Blais]
...
Also, there is something incredibly elegant and simple and compact
about the cons cell, maybe all we need is a good simple cons cell type
and a nice interface on it, so you get both single-linked lists and
trees at the same time...
The first cons cell C extension for
Tim Peters [EMAIL PROTECTED] wrote:
Like Phillip Eby, I use 2-tuples for this when I feel the need
(usually during a backtracking graph search, to keep track of paths
back to the root in a space-efficient way), and am happy with that.
Then there's the whole Python list with append() and
19 matches
Mail list logo
