En Sat, 28 Nov 2009 06:30:44 -0300, Joshua Bronson
escribió:
On Nov 27, 9:36 pm, "Gabriel Genellina"
wrote:
En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr
escribió:
> After much tinkering, I think I have a simpler solution. Just make
> the inverse mapping accessible via an attribute, -
On Mon, Dec 7, 2009 at 5:48 PM, Steven D'Aprano
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 only important that all nod
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 amb
On Mon, Dec 7, 2009 at 2:51 PM, M.-A. Lemburg 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 for a C
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 12:05 PM, M.-A. Lemburg wrote:
> geremy condra wrote:
>> On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg 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 goo
geremy condra wrote:
> On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg 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,
On Mon, Dec 7, 2009 at 7:51 AM, M.-A. Lemburg 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
Carl Banks wrote:
> On Dec 4, 4:42 pm, Lie Ryan wrote:
>> On 12/5/2009 9:41 AM, Carl Banks wrote:
>>
>>
>>
>>
>>
>>> On Dec 4, 12:46 pm, geremy condra 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
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
On Sat, Dec 5, 2009 at 7:18 PM, Raymond Hettinger wrote:
> On Dec 5, 3:22 pm, geremy condra wrote:
>> On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger wrote:
>> > [geremy condra]
>> >> I actually considered using dependencies as an example on the
>> >> "graphine for pythonistas"[1] article, but
On Dec 5, 3:22 pm, geremy condra wrote:
> On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger 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
On Sat, Dec 5, 2009 at 4:39 PM, Raymond Hettinger 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 enough
[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 majorit
On Sat, Dec 5, 2009 at 7:06 AM, Lie Ryan 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
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 th
> > ...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
[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
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 ab
On Fri, Dec 4, 2009 at 8:38 PM, Carl Banks wrote:
> On Dec 4, 4:42 pm, Lie Ryan wrote:
>> On 12/5/2009 9:41 AM, Carl Banks wrote:
>>
>>
>>
>>
>>
>> > On Dec 4, 12:46 pm, geremy condra wrote:
>> > more common than full-blown graph package).
>> >> Sure, its a tree, which is also a graph. In this c
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 Dec 4, 4:42 pm, Lie Ryan wrote:
> On 12/5/2009 9:41 AM, Carl Banks wrote:
>
>
>
>
>
> > On Dec 4, 12:46 pm, geremy condra 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 tha
On Fri, Dec 4, 2009 at 7:42 PM, Lie Ryan wrote:
> On 12/5/2009 9:41 AM, Carl Banks wrote:
>>
>> On Dec 4, 12:46 pm, geremy condra 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 gra
On Fri, Dec 4, 2009 at 5:41 PM, Carl Banks wrote:
> On Dec 4, 12:46 pm, geremy condra 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 seman
On 12/5/2009 9:41 AM, Carl Banks wrote:
On Dec 4, 12:46 pm, geremy condra 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 interf
On Dec 4, 12:46 pm, geremy condra 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
> equivalent.
I'
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 th
On Fri, Dec 4, 2009 at 3:10 PM, Lie Ryan 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 to mind
>>
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
dis
On Fri, Dec 4, 2009 at 2:52 PM, geremy condra wrote:
> On Fri, Dec 4, 2009 at 11:17 AM, MRAB wrote:
>> M.-A. Lemburg wrote:
>>>
>>> geremy condra wrote:
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg wrote:
>
> geremy condra wrote:
>>
>> On Thu, Dec 3, 2009 at 7:04 AM,
M.-A. Lemburg wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg wrote:
geremy condra wrote:
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed graph implementation à la kjGraph
geremy condra wrote:
> On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg wrote:
>> geremy condra wrote:
>>> On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg wrote:
I think the only major CS data type missing from Python is some
form of (fast) directed graph implementation à la kjGraph:
>
On Thu, Dec 3, 2009 at 12:57 PM, M.-A. Lemburg wrote:
> geremy condra wrote:
>> On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg wrote:
>>> I think the only major CS data type missing from Python is some
>>> form of (fast) directed graph implementation à la kjGraph:
>>>
>>> http://gadfly.sourcefo
[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 alrea
geremy condra wrote:
> On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg 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 build
On Thu, Dec 3, 2009 at 7:04 AM, M.-A. Lemburg 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 re
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 ga
In article <9a6902a1-327e-435e-8c9a-b69028994...@u20g2000vbq.googlegroups.com>,
Joshua Bronson 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 concerns, please send
On Dec 1, 9:03 pm, Chris Rebert 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
On Dec 1, 8:17 pm, a...@pythoncraft.com (Aahz) wrote:
> In article
> <85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com>,
> Joshua Bronson wrote:
> >I noticed the phonebook example in your ActiveState recipe and thought
> >you might consider changing it to something like husbands
On Tue, Dec 1, 2009 at 5:17 PM, Aahz wrote:
> In article
> <85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com>,
> Joshua Bronson wrote:
>>
>>I noticed the phonebook example in your ActiveState recipe and thought
>>you might consider changing it to something like husbands to wive
In article <85100df7-a8b0-47e9-a854-ba8a8a2f3...@r31g2000vbi.googlegroups.com>,
Joshua Bronson 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 relation is many-t
On Dec 1, 2:11 pm, 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
[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 approa
On Nov 27, 1:12 pm, Francis Carr 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 original. The result is
On Nov 19, 8:36 pm, Ben Finney wrote:
> Carl Banks writes:
> > On Nov 19, 3:24 pm, Joshua Bronson wrote:
> > Apart from the GPL, 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
On Nov 27, 9:36 pm, "Gabriel Genellina"
wrote:
> En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr
> 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,
En Fri, 27 Nov 2009 15:12:36 -0300, Francis Carr
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 back to the original.
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 inve
On Nov 24, 10:28 pm, Joshua Bronson 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
On Nov 24, 6:49 pm, Gregory Ewing 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 dictionary).
> Tha
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
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 thi
On Nov 19, 3:24 pm, 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:http://bitbucket.org/jab/toys/src/tip/bijection.py
>
> Is thi
On Nov 20, 3:09 pm, Terry Reedy 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 ambiguous and require
On Nov 20, 3:09 pm, Terry Reedy 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 both get
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 sugg
On Nov 19, 9:17 pm, Carl Banks 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 hear it! i'll release it
Carl Banks writes:
> On Nov 19, 3:24 pm, 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:http://bitbucket.org/jab/toys/s
On Nov 19, 3:24 pm, 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:http://bitbucket.org/jab/toys/src/tip/bijection.py
>
> Is thi
On Nov 19, 7:05 pm, Steven D'Aprano 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 the mapping from b ->
a if ever t
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:
> http://bitbucket.org/jab/toys/src/tip/bijecti
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 wel
63 matches
Mail list logo
