The thing is that is it a pretty hard patch to send... If someone is
sending a patch for this file while another patch is removing this
file and creating three others... If that's how HG works ;-)
Nathann
On Oct 7, 2:39 am, Jason Grout jason-s...@creativetrax.com wrote:
Robert Miller wrote:
On Thu, 08 Oct 2009 at 06:11AM -0700, Nathann Cohen wrote:
The thing is that is it a pretty hard patch to send... If someone is
sending a patch for this file while another patch is removing this
file and creating three others... If that's how HG works ;-)
Mercurial should support this. If the
http://groups.google.com/group/sage-devel/browse_thread/thread/b9f22846f7ec8c64
To continue the discussion :-)
Nathann
On Oct 8, 3:42 pm, Dan Drake dr...@kaist.edu wrote:
On Thu, 08 Oct 2009 at 06:11AM -0700, Nathann Cohen wrote:
The thing is that is it a pretty hard patch to send... If
On Oct 8, 2009, at 6:42 AM, Dan Drake wrote:
On Thu, 08 Oct 2009 at 06:11AM -0700, Nathann Cohen wrote:
The thing is that is it a pretty hard patch to send... If someone is
sending a patch for this file while another patch is removing this
file and creating three others... If that's how HG
I have no clue how to write what you are describing. Graph.neighbors
would be a subobject, does that mean an independent class ? Wouldn't
this slow down the whole Graph class, as these functions are among
the
most used ? Here I feel that I do not know Python enough to
help.. :-)
Rob Beezer wrote:
On Oct 3, 2:47 am, Nathann Cohen nathann.co...@gmail.com wrote:
DiGraph.out_neighbors() and DiGraph.in_neighbors() would be much easier to
find and more natural...
I'd suggest
neighbors_in()
neighbors_out()
neighbors()
to make tab completion easier and to group
On Tue, Oct 6, 2009 at 8:30 AM, Nick Alexander ncalexan...@gmail.com wrote:
That's probably for the best -- it was a pretty bad idea, and any
implementation that one comes up with is probably going to be terrible
in one way or another. Don't do it.
I (and you?) did something similar for
However, Robert Miller has been notably silent on this topic. We
should try to get him to weigh in before making any sweeping
decisions, since he's (at the very least) the most familiar with the
code.
I have spent months trying to make function calls just like, e.g.
G.predecessors(3), as
As far as it being *possible* to split up graph.py... It's a ten
minute job, but nobody's done it. You could split it in three right
away by having generic_graph.py, graph.py and digraph.py.
+1
Nick
--~--~-~--~~~---~--~~
To post to this group, send an email
Robert Miller wrote:
However, Robert Miller has been notably silent on this topic. We
should try to get him to weigh in before making any sweeping
decisions, since he's (at the very least) the most familiar with the
code.
I have spent months trying to make function calls just like, e.g.
On Sat, Oct 03, 2009 at 03:26:05PM -0700, Robert Bradshaw wrote:
On Oct 3, 2009, at 1:38 PM, Tom Boothby wrote:
On Sat, Oct 3, 2009 at 12:52 PM, Rob Beezer
goo...@beezer.cotse.net wrote:
On Oct 3, 2:47 am, Nathann Cohen nathann.co...@gmail.com wrote:
DiGraph.out_neighbors() and
I would be glad to write a patch changing the names of these functions
to neighbors_out or neighbors_in ( if all of us are ok about it ), but
I have no clue how to write what you are describing. Graph.neighbors
would be a subobject, does that mean an independent class ? Wouldn't
this slow down
On Sun, Oct 4, 2009 at 4:35 AM, Nathann Cohen nathann.co...@gmail.com wrote:
I would be glad to write a patch changing the names of these functions
to neighbors_out or neighbors_in ( if all of us are ok about it ), but
That's fine by me.
I have no clue how to write what you are describing.
I don't think the names you're suggesting are any more natural or easy
to find. I rather like successors and predecessors -- though I'd name
them parents and children, myself.
On Sat, Oct 3, 2009 at 2:47 AM, Nathann Cohen nathann.co...@gmail.com wrote:
Hello everybody
I thought odd, a
On Oct 3, 2:47 am, Nathann Cohen nathann.co...@gmail.com wrote:
DiGraph.out_neighbors() and DiGraph.in_neighbors() would be much easier to
find and more natural...
I'd suggest
neighbors_in()
neighbors_out()
neighbors()
to make tab completion easier and to group them next to each other
when
On Sat, Oct 3, 2009 at 12:52 PM, Rob Beezer goo...@beezer.cotse.net wrote:
On Oct 3, 2:47 am, Nathann Cohen nathann.co...@gmail.com wrote:
DiGraph.out_neighbors() and DiGraph.in_neighbors() would be much easier to
find and more natural...
I'd suggest
neighbors_in()
neighbors_out()
On Oct 3, 2009, at 1:38 PM, Tom Boothby wrote:
On Sat, Oct 3, 2009 at 12:52 PM, Rob Beezer
goo...@beezer.cotse.net wrote:
On Oct 3, 2:47 am, Nathann Cohen nathann.co...@gmail.com wrote:
DiGraph.out_neighbors() and DiGraph.in_neighbors() would be much
easier to
find and more natural...
On Oct 3, 1:38 pm, Tom Boothby tomas.boot...@gmail.com wrote:
This would clean up tab completion, and maybe even make it possible
to
break the 12k line graph.py into more files. Thoughts?
Anything that would naturally slim down graph.py would be welcome.
There is a noticeable lag every time
On Sat, Oct 3, 2009 at 8:01 PM, Rob Beezer goo...@beezer.cotse.net wrote:
On Oct 3, 1:38 pm, Tom Boothby tomas.boot...@gmail.com wrote:
This would clean up tab completion, and maybe even make it possible
to
break the 12k line graph.py into more files. Thoughts?
Anything that would
19 matches
Mail list logo
