On Wednesday, 26 August 2015 00:30:17 UTC-7, Johan S. R. Nielsen wrote: > > > 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. >
yes, this is exactly how I see it, too. > > 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). > indeed. > > 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. > there is no harm in duplication; there could be things in both places, e.g. SymmetricGroup deserves to be in the global namespace, as well as as in groups.SymmetricGroup (or even as groups.Symmetric, as already suggested in this thread) > > Though I know nothing about two-graphs, it therefore seems that I would > vote for putting TwoGraph in graphs.<tab>. > well, we talk about designs.TwoGraph, not graphs.... (TwoGraph is a kind of 3-uniform hypergraph/design, not a graph) Dima > > > > > 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.
