En Sat, 28 Nov 2009 06:30:44 -0300, Joshua Bronson jabron...@gmail.com
escribió:
On Nov 27, 9:36 pm, Gabriel Genellina gagsl-...@yahoo.com.ar
wrote:
En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr
coldtort...@gmail.com escribió:
After much tinkering, I think I have a simpler solution.
Terry Reedy wrote:
M.-A. Lemburg wrote:
Integrating an easy-to-use graph library into the collections
module (and it's C companion) is good idea.
This would have to be written in C, though,
That's currently in the works, along with database backing.
We'd welcome any help though... hint,
Carl Banks wrote:
On Dec 4, 4:42 pm, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condradebat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me
On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg m...@egenix.com wrote:
Terry Reedy wrote:
M.-A. Lemburg wrote:
Integrating an easy-to-use graph library into the collections
module (and it's C companion) is good idea.
This would have to be written in C, though,
That's currently in the works,
geremy condra wrote:
On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg m...@egenix.com wrote:
Terry Reedy wrote:
M.-A. Lemburg wrote:
Integrating an easy-to-use graph library into the collections
module (and it's C companion) is good idea.
This would have to be written in C, though,
That's
On Mon, Dec 7, 2009 at 12:05 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg m...@egenix.com wrote:
Terry Reedy wrote:
M.-A. Lemburg wrote:
Integrating an easy-to-use graph library into the collections
module (and it's C companion)
geremy condra wrote:
How interested are you in a C port of graphine? I haven't had
any specific requests for it, but if its something you need I
can shuffle it towards the top of the to do pile.
There are two main reasons for a C implementation:
1. performance
2. memory footprint
These
On Mon, Dec 7, 2009 at 2:51 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
How interested are you in a C port of graphine? I haven't had
any specific requests for it, but if its something you need I
can shuffle it towards the top of the to do pile.
There are two main reasons
On Mon, 07 Dec 2009 17:23:24 -0500, geremy condra wrote:
* Graph.__iter__ could be mapped to an iterator using
the fastest traversal method for the graph nodes (ie. order does not
matter, it's only important that all nodes are found as fast as
possible)
Again, it seems ambiguous as
On Mon, Dec 7, 2009 at 5:48 PM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote:
On Mon, 07 Dec 2009 17:23:24 -0500, geremy condra wrote:
* Graph.__iter__ could be mapped to an iterator using
the fastest traversal method for the graph nodes (ie. order does not
matter, it's
[Me]
* we've already got one (actually two).
The two dictionary approach...
[Francis Carr]
Solutions such as bidict just automate the two-dict approach.
They do so at the expense of implementing a new API to support it and
at the expense with having non-obvious behaviors (i.e. how it
...sqlite3 provides another way...
In many many cases, using a dB (even a lightweight such as sqlite3) is
swatting the fly with a sledgehammer :-)
I'm sure it seems that way, but look at the generic description of the
problem: I have a list of n-ary tuples with named fields and would
like
On 12/5/2009 4:18 PM, Steven D'Aprano wrote:
Tree is better than Graph
not having Tree and Graph package in the standard library force most
people to find List-based solution.
If you have to be *forced* to use a list-based solution, that's a good
sign that a list is *not* the right tool for
On Sat, Dec 5, 2009 at 7:06 AM, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 4:18 PM, Steven D'Aprano wrote:
Tree is better than Graph
not having Tree and Graph package in the standard library force most
people to find List-based solution.
If you have to be *forced* to use a list-based
[geremy condra]
I actually considered using dependencies as an example on the
graphine for pythonistas[1] article, but decided to do the maze
run instead. In any event, the uses of graphs in general computing
are well enough established that I don't really think that's where
the majority of
On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger pyt...@rcn.com wrote:
[geremy condra]
I actually considered using dependencies as an example on the
graphine for pythonistas[1] article, but decided to do the maze
run instead. In any event, the uses of graphs in general computing
are well
On Dec 5, 3:22 pm, geremy condra debat...@gmail.com wrote:
On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger pyt...@rcn.com wrote:
[geremy condra]
I actually considered using dependencies as an example on the
graphine for pythonistas[1] article, but decided to do the maze
run instead. In
On Sat, Dec 5, 2009 at 7:18 PM, Raymond Hettinger pyt...@rcn.com wrote:
On Dec 5, 3:22 pm, geremy condra debat...@gmail.com wrote:
On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger pyt...@rcn.com wrote:
[geremy condra]
I actually considered using dependencies as an example on the
graphine
geremy condra wrote:
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg m...@egenix.com wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed graph implementation à
M.-A. Lemburg wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg m...@egenix.com wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed
On Fri, Dec 4, 2009 at 2:52 PM, geremy condra debat...@gmail.com wrote:
On Fri, Dec 4, 2009 at 11:17 AM, MRAB pyt...@mrabarnett.plus.com wrote:
M.-A. Lemburg wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
On Thu, Dec
On 12/5/2009 6:53 AM, geremy condra wrote:
To be fair, I don't think you'd have to look very far to find places
where a graph representation is approximated using some
combination of dicts, sets, and lists. ElementTree comes to mind
immediately, and the dict-of-dicts idea for logging recently
On Fri, Dec 4, 2009 at 3:10 PM, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 6:53 AM, geremy condra wrote:
To be fair, I don't think you'd have to look very far to find places
where a graph representation is approximated using some
combination of dicts, sets, and lists. ElementTree comes
M.-A. Lemburg wrote:
Integrating an easy-to-use graph library into the collections
module (and it's C companion) is good idea.
This would have to be written in C, though,
That's currently in the works, along with database backing.
We'd welcome any help though... hint, hint...
The current
On Dec 4, 12:46 pm, geremy condra debat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me more like a directed acyclic graph than anything, but its
pretty much just semantics since the interface is functionally
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condradebat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me more like a directed acyclic graph than anything, but its
pretty much just
On Fri, Dec 4, 2009 at 5:41 PM, Carl Banks pavlovevide...@gmail.com wrote:
On Dec 4, 12:46 pm, geremy condra debat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me more like a directed acyclic graph than
On Fri, Dec 4, 2009 at 7:42 PM, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condradebat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me more like a
On Dec 4, 4:42 pm, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condradebat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a tree, which is also a graph. In this case it looks to
me more like a
On 12/5/2009 12:38 PM, geremy condra wrote:
Where a list will do, use a list- duh. But when you need a graph, you
shouldn't have to homebrew an implementation any more than you
should have to homebrew an odict or named tuple, both of which
are substantially easier to get right than a graph is.
On Fri, Dec 4, 2009 at 8:38 PM, Carl Banks pavlovevide...@gmail.com wrote:
On Dec 4, 4:42 pm, Lie Ryan lie.1...@gmail.com wrote:
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condradebat...@gmail.com wrote:
more common than full-blown graph package).
Sure, its a
On Sat, 05 Dec 2009 11:42:15 +1100, Lie Ryan wrote:
I think this could be an interpretation of the Zen:
Simple is better than complex.
Complex is better than complicated.
can be read as:
List is better than Tree
Because O(N) searches are better than O(log N) searches. Not.
How about
Raymond Hettinger wrote:
[Joshua Bronson]
Raymond, do you think there might be any future in including a built-
in bidict data structure in Python?
I don't think so. There are several forces working against it:
* the recipe is new, so it hasn't had a chance to mature
or to gain a fan
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg m...@egenix.com wrote:
Raymond Hettinger wrote:
[Joshua Bronson]
Raymond, do you think there might be any future in including a built-
in bidict data structure in Python?
I don't think so. There are several forces working against it:
* the
geremy condra wrote:
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg m...@egenix.com wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed graph implementation à la kjGraph:
http://gadfly.sourceforge.net/kjbuckets.html
With these, you can easily
[In re R. Hettinger's critiques]
* it extends the language with arcane syntax tricks...
I think most of these in the current version of J. Bronson's bidict
can be left unused, or removed altogether. In almost all cases, a
bidict should be accessed as an ordinary python dict.
* we've already
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg m...@egenix.com wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg m...@egenix.com wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed graph implementation à la kjGraph:
On Dec 1, 8:17 pm, a...@pythoncraft.com (Aahz) wrote:
In article
85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com,
Joshua Bronson jabron...@gmail.com wrote:
I noticed the phonebook example in your ActiveState recipe and thought
you might consider changing it to something
On Dec 1, 9:03 pm, Chris Rebert c...@rebertia.com wrote:
Reminds me of this quite funny blog post:
Gay marriage: the database engineering perspective
http://qntm.org/?gay
amazing
--
http://mail.python.org/mailman/listinfo/python-list
In article 9a6902a1-327e-435e-8c9a-b69028994...@u20g2000vbq.googlegroups.com,
Joshua Bronson jabron...@gmail.com wrote:
At any rate, apologies to the community for my heteronormative
example. It was merely pedagogical and reflects nothing about my
personal views! If you have any further
On Nov 27, 1:12 pm, Francis Carr coldtort...@gmail.com wrote:
I was really inspired by this discussion thread! :-)
After much tinkering, I think I have a simpler solution. Just make
the inverse mapping accessible via an attribute, -AND- bind the
inverse of -THAT- mapping back to the
[Joshua Bronson]
Raymond, do you think there might be any future in including a built-
in bidict data structure in Python?
I don't think so. There are several forces working against it:
* the recipe is new, so it hasn't had a chance to mature
or to gain a fan club.
* there are many
On Dec 1, 2:11 pm, Raymond Hettinger pyt...@rcn.com wrote:
[Joshua Bronson]
Raymond, do you think there might be any future in including a built-
in bidict data structure in Python?
I don't think so. There are several forces working against it:
* the recipe is new, so it hasn't had a
In article 85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com,
Joshua Bronson jabron...@gmail.com wrote:
I noticed the phonebook example in your ActiveState recipe and thought
you might consider changing it to something like husbands to wives,
since the names-to-phone-numbers
On Tue, Dec 1, 2009 at 5:17 PM, Aahz a...@pythoncraft.com wrote:
In article
85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com,
Joshua Bronson jabron...@gmail.com wrote:
I noticed the phonebook example in your ActiveState recipe and thought
you might consider changing it to
On Nov 27, 9:36 pm, Gabriel Genellina gagsl-...@yahoo.com.ar
wrote:
En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr coldtort...@gmail.com
escribió:
I was really inspired by this discussion thread! :-)
After much tinkering, I think I have a simpler solution. Just make
the inverse
On Nov 19, 8:36 pm, Ben Finney ben+pyt...@benfinney.id.au wrote:
Carl Banks pavlovevide...@gmail.com writes:
On Nov 19, 3:24 pm, Joshua Bronson jabron...@gmail.com wrote:
Apart from the GPL, it seems perfectly fine to release, and looks like
an interesting strategy. I've wanted one of those
I was really inspired by this discussion thread! :-)
After much tinkering, I think I have a simpler solution. Just make
the inverse mapping accessible via an attribute, -AND- bind the
inverse of -THAT- mapping back to the original. The result is a
python dict with NO NEW METHODS except this
En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr coldtort...@gmail.com
escribió:
I was really inspired by this discussion thread! :-)
After much tinkering, I think I have a simpler solution. Just make
the inverse mapping accessible via an attribute, -AND- bind the
inverse of -THAT- mapping
On Nov 24, 10:28 pm, Joshua Bronson jabron...@gmail.com wrote:
bidict it is!
now available at http://bitbucket.org/jab/toys/src/tip/bidict.py
and now featuring new shiny namedbidict goodness!
as always, feedback welcome.
josh
--
http://mail.python.org/mailman/listinfo/python-list
Hey Raymond,
Thanks for your thoughtful reply! I think your idea for a class-
generation approach in the spirit of namedtuple is brilliant; looking
forward to coding this up and seeing how it feels to use it.
(By the way, it occurred to me that bijection is perhaps the wrong
term to use for this
Joshua Bronson wrote:
So I'm
thinking of renaming the class injectivedict or idict instead of
bijection. Is that crazy?)
I think you'd be better off calling it something more
down-to-earth such as bidict (bidirectional dictionary).
That way people without an advanced degree in mathematics
have
On Nov 24, 6:49 pm, Gregory Ewing greg.ew...@canterbury.ac.nz wrote:
Joshua Bronson wrote:
So I'm
thinking of renaming the class injectivedict or idict instead of
bijection. Is that crazy?)
I think you'd be better off calling it something more
down-to-earth such as bidict (bidirectional
On Nov 19, 3:24 pm, Joshua Bronson jabron...@gmail.com wrote:
I couldn't find a library providing a bijective map data structure
(allowing for constant-time lookups by value) in the few minutes I
looked, so I took a few more minutes to code one
I couldn't find a library providing a bijective map data structure
(allowing for constant-time lookups by value) in the few minutes I
looked, so I took a few more minutes to code one up:
http://bitbucket.org/jab/toys/src/tip/bijection.py
Is this at all worth releasing? Comments and suggestions
On Thu, 19 Nov 2009 15:24:46 -0800, Joshua Bronson wrote:
I couldn't find a library providing a bijective map data structure
(allowing for constant-time lookups by value) in the few minutes I
looked, so I took a few more minutes to code one up:
On Nov 19, 7:05 pm, Steven D'Aprano st...@remove-this-
cybersource.com.au wrote:
If I want a mapping a - b, I generally just create a dict {a:b, b:a}.
What is the advantages or disadvantages of your code over the simplicity
of the dict approach?
Well for one, you don't have to manually update
On Nov 19, 3:24 pm, Joshua Bronson jabron...@gmail.com wrote:
I couldn't find a library providing a bijective map data structure
(allowing for constant-time lookups by value) in the few minutes I
looked, so I took a few more minutes to code one
Carl Banks pavlovevide...@gmail.com writes:
On Nov 19, 3:24 pm, Joshua Bronson jabron...@gmail.com wrote:
I couldn't find a library providing a bijective map data structure
(allowing for constant-time lookups by value) in the few minutes I
looked, so I took a few more minutes to code one
On Nov 19, 9:17 pm, Carl Banks pavlovevide...@gmail.com wrote:
Apart from the GPL
what Ben said :)
it seems perfectly fine to release, and looks like
an interesting strategy. I've wanted one of those once in a while,
never enough to bother looking for one or writing one myself.
glad to
Joshua Bronson wrote:
Anyone have any other feedback? For instance, is offering the __call__
syntax for the inverse mapping wonderful or terrible, or maybe both?
Terrible ;-)
Use standard subscripting with slices, and only that, to both get and set.
Let m[4] == m[4:] == 'abc' # m[4:] is
On Nov 20, 3:09 pm, Terry Reedy tjre...@udel.edu wrote:
Joshua Bronson wrote:
Anyone have any other feedback? For instance, is offering the __call__
syntax for the inverse mapping wonderful or terrible, or maybe both?
Terrible ;-)
Use standard subscripting with slices, and only that, to
On Nov 20, 3:09 pm, Terry Reedy tjre...@udel.edu wrote:
Use standard subscripting with slices, and only that, to both get and set.
i did this for __delitem__ too, so you can do e.g. del m[:'abc'].
In fact, to emphasize the symmetry of the bijective map, consider
disallowing m[key] as
63 matches
Mail list logo
