On Jan 10, 2010, at 2:49 AM, Nathann Cohen wrote:
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.
Of course, this means that you can't do g.is_<tab> to see all tests
that are supported. You're making this use decision for the user.
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 !
If the compartmentalization in code matches the compartmentalization
in the users mind. Now if g.trees contained aliases to the existing
methods (doable with __getattr__), then a single method could be put
into multiple spots.
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 ).
That could work.
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.
Why is that too many? I like being able to type g.<tab> and see every
single method that is available. If one is interested in trees,
g.tree<tab>[<tab>] gives a smaller subset. Or read the documentation.
For consistency, would you expect this to be done with everything else
in Sage that has lots (for some value of lots) of methods? Are there
any other Python packages that do this?
Of course, all of the above is just my opinion, it's worth hearing
what other people have to say too.
- 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
