Hi Nathann and Robert!
On 10 Jan., 10:59, Robert Bradshaw <rober...@math.washington.edu>
wrote:
> > I was thinking about the huge list of functions we have at the moment
> > in the Graph class, and the length of Graph.py.
I am a bit puzzled: Do you really talk about *functions*? Should there
be any function *at all*, except for constructors?
Or are you talking about *methods*?
> > 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.
Again, perhaps I don't properly understand. Is the plan as follows?
- There are certain *functions* "def foobar(self)" defined in
Graph.clique
- A graph instance has methods that essentially just call the
functions from Graph.clique
- You want to have tab completion for these methods
If this is what you intend:
- You may have a __getattr__ method for graphs. Whenever an attribute
of a graph is requested that starts with "clique_" (say,
g.clique_foobar) then __getattr__ returns the corresponding function
from clique (here: the function foobar). In that way, the zillions of
functions/methods could be neatly distributed/sorted into various
files, and it is straight forward to extend.
- For obtaining tab completion: IIRC, it suffices if __getattr__
returns a list of available method names (e.g. "clique_foobar") if the
attribute __methods__ (or was it __members__?) is requested.
> I.e. you'd have to write
>
> sage: g.trees.is_tree(g)
>
> unless you did some trickery behind the scenes.
Perhaps the above is the trickery? Although I used those things for
elements of infinite polynomial rings, I am still not sure if it
doesn't qualify as a nasty hack, though.
> 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.
> ...
And this is why it shouldn't be functions but methods?
> 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).
Note that this would not be covered by the above trickery ("let
__getattr__ return the list of function names if __methods__ is
requested"); it would be needed to work on tab completion per se.
I wonder if this is a nice feature, though. Imagine you do "g.i<TAB>"
-- should it really return *all* method names that *contain* (rather
than start with) an "i"? This wouldn't be helpful, IMHO.
Cheers,
Simon
--
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
