Hi,
In catalogues, I would only put classes and functions that are directly
useful for users and should be easily accessible. It that way, it is
exactly like exporting into the global name space, except that the
catalogue's classes and functions are strongly related, and possibly
more specialised and appeals to a smaller subset of users.
In particular, I don't feel that catalogues should only contain famous
constructions and families (PetersenGraph, NathannCohenGraph, etc.). For
one thing, the distinction is not well-defined: there is no real
difference between "generic" constructors and gigantic but specifically
named families of objects (e.g. Alternant codes in coding theory).
To sum up, I would put a class/function in the respective catalogue if:
1) It's "polished" as in nicely callable by the user in a Sage session.
2) It's reasonably useful for people interested in the field of the
catalogue.
3) It's not imported in the global name space.
Though I know nothing about two-graphs, it therefore seems that I would
vote for putting TwoGraph in graphs.<tab>.
Best,
Johan
Dima Pasechnik writes:
> On Tuesday, 25 August 2015 11:20:39 UTC-7, Nathann Cohen wrote:
>>
>> Hello everybody,
>>
>> In a discussion on a ticket, Dima raised an interesting question: what
>> are catalogs (i.e. groups.<tab>, codes.<tab>, graphs.<tab>) *supposed*
>> to contain?
>>
>> To me, it seems natural to have "graphs.PetersenGraph", but not
>> "graphs.Graph" (the class constructor) nor "graphs.DiGraph".
>>
>> Similarly, we do not have a "groups.permutations.PermutationGroup"
>> even though the groups that can be obtained from
>> "groups.permutations.<tab>" are all permutation groups !
>>
>> It is a needless obstacle from a user point of view, that a non-exposed
> through catalog or global namespace
> class has to be explicitly imported (sometimes via an arcane sequence of
> module names) before one can create an object from it.
> (Needless to say, such classes are hard to discover, too).
>
> Clearly there are classes with constructors meant to be called directly by
> a user, and these have to be exposed in
> one way or another, from useability point of view.
> (I wrote a bit longer explanation here:
> http://trac.sagemath.org/ticket/18972#comment:119)
>
>
>
>
>
>> In the present case, we discuss with Dima whether we should include a
>> class in designs.<tab> (whose role is similar to Graph, or to
>> IncidenceStructure). It is important to note that this class is *not*
>> exported in the global namespace. We expect it to be rarely used,
>> however.
>>
>> Nathann
>>
>> P.S.: If we make a difference between classes exported in the global
>> namespace and the others, we cannot have "some classes" in catalog X
>> because they are not exported, and not have other because those *are*
>> exported.
>>
--
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
