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: > >> 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 fast as possible. There is still a lot of work > > left, but things like G.neighbors().in()... or whatever sounds > > alarmingly to me like extra unnecessary Python layers around a > > function which you want ABSOLUTELY no Python involved in at all, other > > than the initial function call. Name changes and aliases I can live > > with. Extra layers of Python function calls for no reason other than > > tab completion prettiness, this is really bad. Especially when it's a > > function as basic as neighbors, which gets used in almost every graph > > theory algorithm out there. Imagine the future "embarrassing" thread > > where a 10x speedup is discovered by avoiding this exact approach... > > +1 > > I'm with Robert. > > > 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 too. > > Jason > > -- > Jason Grout --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
