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 ho
http://groups.google.com/group/sage-devel/browse_thread/thread/b9f22846f7ec8c64
To continue the discussion :-)
Nathann
On Oct 8, 3:42 pm, 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
> > s
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 th
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 wrote:
> Robert Miller wrote:
> >> However, Robert Miller h
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 lik
> 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
> 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
On Tue, Oct 6, 2009 at 8:30 AM, Nick Alexander 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 torsion subgroup
Rob Beezer wrote:
> On Oct 3, 2:47 am, Nathann Cohen 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 e
>> 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..
On Sun, Oct 4, 2009 at 4:35 AM, Nathann Cohen 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. Graph.neighbors
> wo
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 the
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
> > wrote:
> >>
> >> On Oct 3, 2:47 am, Nathann Cohen wrote:
> >>> DiGraph.out_neighbors() and DiGraph.in_neighbors() would be
On Sat, Oct 3, 2009 at 8:01 PM, Rob Beezer wrote:
>
> On Oct 3, 1:38 pm, Tom Boothby 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 welco
On Oct 3, 1:38 pm, Tom Boothby 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 I load the file in my
On Oct 3, 2009, at 1:38 PM, Tom Boothby wrote:
> On Sat, Oct 3, 2009 at 12:52 PM, Rob Beezer
> wrote:
>>
>> On Oct 3, 2:47 am, Nathann Cohen wrote:
>>> DiGraph.out_neighbors() and DiGraph.in_neighbors() would be much
>>> easier to
>>> find and more natural...
>>
>> I'd suggest
>>
>> neighbo
On Sat, Oct 3, 2009 at 12:52 PM, Rob Beezer wrote:
>
> On Oct 3, 2:47 am, Nathann Cohen 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()
Now that *is* more natural.
On Oct 3, 2:47 am, Nathann Cohen 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 browsing commands with
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 wrote:
> Hello everybody
>
> I thought odd, a few days ago when
19 matches
Mail list logo
