On Jan 10, 2010, at 12:15 AM, Nathann Cohen wrote:
Hello everybody !!! This is a copy of a mail I sent to Robert Miller,
who may require a larger audience :-)
-------------------
I was thinking about the huge list of functions we have at the moment
in the Graph class, and the length of Graph.py.
Well, I am at the moment convinced ( if you are not of the same mind,
please tell me ), that the best way would be to create different files
for different "types" of functions, and import them the following way
: let us say we have such a file named graph/cliques.py containing all
the functions beginning by "cliques". We sould then just have to add
in the "main" file graph.py the line : from sage.graphs import cliques
This way, when we use tab completion on "g." or on "Graph.", see the
module "clique" , on which we could then use tab completion again
through "Graph.clique."
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.
This would actually be a pretty natural way for the user to find
functions.... I spent "some time" tring to sort this long list : I
tought this could give good results, so I gave it a try, but this by
itself is no reason not to discard it totally if you do not like the
idea. Anyway after sorting this all is mixed up in my head, so I will
trust your judgement :-)
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.
sage: import this
The Zen of Python, by Tim Peters
...
Flat is better than nested.
...
If it's a question of file length, that can be split up without
changing the interface. If it's a concern of overwhelming the user
with too many methods on g.[tab], I think the answer is to make tab
completion smarter (e.g. g.iso[tab] could find is_isomorphism).
If you like this idea, we will obviously have to go over it several
times, moving things around and renaming others... :-)
Have you considered backwards compatibility?
- Robert
--
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
