I think an argument that this function is badly named is very sensible. Maybe a better name would be "to_component_sizes". Why not just try changing the name, and see how much work that is for the findstat group to adapt. It might be that this does not want to be named, after all, and that simply an unnamed method needs to be registered.
Do you feel that you own the class "Graph"? And get to decide what is interesting and what is not relating to Graphs? If so, then indeed there is a problem. What bothers you particularly? To see those methods in the code? To see it appear when you press <Tab>? Clarifying that part would help making everyone happy. Paul On Wed, May 28, 2014 at 9:52 PM, Nathann Cohen <nathann.co...@gmail.com>wrote: > Yo ! > > > Currently that ticket's description is in complete > > contradiction to what you seem to describe on the mailing list (which > seems > > more sensible to me). In particular the title of the ticket is "Rename" > > while the last line says "remove". > > Not my doing. When I posted my last comment on this ticket I set it to > "positive_review" and "wontfix" because I gave up. I cannot do anything > against a reviewer like you. > Afterwards Ralf changed some stuff, then you set the ticket to > needs_review, then it was set to needs_work by somebody else. Honestly it > is not my ticket anymore, do what you want with it. > > About the difference you see between my ticket, which said "remove the > function" and what I said here in my previous post : > I had not noticed before that having a hidden function was actually a nice > middle-ground. You can create functions "for semantics only" if it is > useful, but this is an "internal mechanism" of Sage. If you need a function > which transforms a Graph into a partition of integer to this end it is > good, and you can name it Graph._to_partition if you like, but > Graph.to_partition means that the function is unclear and not something > users should see. And even if a better name is to be found, I would still > claim that this function is really not useful to users (though it may be > useful for the databases you want to build), and as such has nothing to do > in the (already quite crowded) list of graph functions. > > So, yeah. Basically, I had not noticed that having a hidden function with > a decorator on it (named to_partition if needed) was a good middle ground. > > > As long as this is the case, Nathann's arguments are incoherent and > > contradictory, and any conversation on the list will turn in circles. > > > > My summary assessment so far is that Nathann is wrong, the > implementation by > > findstat of their ideas is poor, and the burden is on all of us to > improve > > it, particularly those who care the most. That's the way sage development > > works, as far as I understand it. Maybe I will be swayed by good > arguments > > from Nathann, who has opened the ticket. I am genuinely keeping an open > mind > > about implementation. I want him to improve what's there, not remove, if > he > > cares enough. > > Whatever. > > Nathann > > -- > You received this message because you are subscribed to the Google Groups > "sage-combinat-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-combinat-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-combinat-de...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-combinat-devel. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
