> This won't work for methods, as the functions in clique won't get a bound > self. I.e. you'd have to write > > sage: g.trees.is_tree(g) > > unless you did some trickery behind the scenes.
Yes, I thought we could replace g.is_trees by g.trees.is_tree > I would actually find this interface less easy to use--the fact that you're > asking for any discussion about where functions should go means that it's > not 100% obvious, so an end user might end up having to search multiple > subspaces to find the method desired method--or even to see a method doesn't > exist. Namespaces can be good, but usually only when there's an actual > hierarchy. Not at all. * First, the discussion on the names hasn't even begun. We may all agree on this classification :-) * Most importantly, your deduction is not correct : What I spent some time on was this : Do we need to create subcategories according to what the functions does : g.test_class.is_tree Or according to the "classes" g.trees.is_tree Which means : do we regroup all the is_* methods somewhere together, or do we let them live in a subsection describing what they test ? I thought the second option made more sense ( if a user is interested in a special category, he will list the methods in this category and see the corresponding is_ function. This way one will use many methods grouped inside the same subsection according to what he wants to do. This all means that we can have many discussions among developpers on how to write it, but it may be easy to find for the user whatever classification we chose. If the user wanting to test if a graph is a tree see a subsection test_class, he will go for it and explore it. If he wants to test if a graph is a tree and sees a subsection named trees, he will definitely explore it ! > sage: import this > The Zen of Python, by Tim Peters > ... > Flat is better than nested. > ... I respect this kind of answer :-) > Have you considered backwards compatibility? It would obviously not be backward-compatible ( we could create aliases, though, and remove the aliased functions from the tab completion ( -> backward compatibility + change is the coders' behaviour ). The thing is that we have at the moment something like 210 functions in the Graph class. We can not really keep on adding the new ones without caring about what it is becoming. Nathann
-- 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
