name space pollution

[Franco Saliola]

Michael Abshoff wrote in the comments to trac ticket #4653:

> one issue that might be worth considering now before merging is
> "name space pollution", i.e. there was some discussion at SD 11
> that it would be better to have most of the functionality of certain
> packages like quadratic forms not in the global namespace.
> I am not sure what the situation with words is (sorry, no time to
> apply the patch and play :)), but it would be nice if most of the
> functionality would be in
>
> words.$FOO
>
> Sooner or later things will start colliding in the global namespace,
> so the time to fix this would be pre-merge :)

I like this idea for several reasons, but it is something that needs
to be discussed since there should be a consistent way to do this
across all Sage packages/libraries. So let's discuss it. What is the
best way to do this? (I wasn't at Sage Days 11, so I don't know what
was decided.)

One thing that comes to mind, from a user's perspective, is that there
should be a consistent way to load all functions from a given package
into the global name space. Something like:

LoadPackage(words)

or

from words import *

I prefer the latter, actually.

Another related issue, perhaps this should be a different thread, is
pre-defined examples of objects. I am going to use graphs to
illustrate what I mean here. One can write, for example,

sage: graphs.CompleteGraph(5)
Complete graph: Graph on 3 vertices

But there are other objects lying around in the global name space
which should probably be access by such interface. And this should
also be consistent across Sage. Is graphs a suitable name for this?
Should it be something like GraphExamples or GraphConstructor or
something else instead? One problem with the name graphs is that some
sage-combinat developer is going to come along and define the
combinatorial class of all graphs and name it Graphs. Then graphs and
Graphs might have different behaviour unless one allows something like
this:

sage: Graphs(3)
Graphs on 3 vertices
sage: Graphs.CompleteGraph(5)
Complete graph: Graph on 3 vertices

Thoughts/comments?

Franco

--

[William Stein]

I really like

sage: finance.[tab]

I don't like explicitly forcing people to import stuff before they can use it
at all. Thus I much prefer

$ sage
....
sage: finance.[tab]

and I don't like

$ sage
...
sage: import sage.finance as finance
sage: finace.[tab]

I do like various domains with lots of functions to have their
functionality gathered together under
a namespace. That said, I'm not for some massive reorganization of
the current global namespace, since that wold break a huge amount of
existing code -- both in Sage and out (e.g., the examples at
wiki.sagemath.org/interact).

And it's not the end of the world that len(globals()) is large. It's
only a problem to me when there are specific reasons it is a problem.

-- William

[mabshoff]

<SNIP>

> I really like
>
>   sage: finance.[tab]
>
> I don't like explicitly forcing people to import stuff before they can use it
> at all.  Thus I much prefer
>
> $ sage
> ....
> sage: finance.[tab]
>
> and I don't like
>
> $ sage
> ...
> sage: import sage.finance as finance
> sage: finace.[tab]
>
> I do like various domains with lots of functions to have their
> functionality gathered together under
> a namespace.     That said, I'm not for some massive reorganization of
> the current global namespace, since that wold break a huge amount of
> existing code -- both in Sage and out (e.g., the examples at
> wiki.sagemath.org/interact).
>
> And it's not the end of the world that len(globals()) is large.  It's
> only a problem to me when there are specific reasons it is a problem.
>
>    -- William

Ok, that is pretty much what I wanted to express, i.e. having most
things of a given subsystem gathered under $SUBSYSTEM.[tab]. I did not
mean that one would have to import things, so my use of "global
namespace" was not in the pythonic way.

Cheers,

Michael

[koffie]

Are there some general guidelines on how to use the namespaces in
sage. Like: which function's should be accesible from which namespace
(global v.s. local and maybe some hierachical structure in the local
namespace).
I think some guidelines on this would improve the userfriendliness of
sage a big deal in the long run.
I personally find the polution of the global namespace and some local
namespace's to get already a bit annoying and making the [tab]
funtionality a whole less usefull then it could be for when quickly
trying to find some funtion.

Here are just some random ideas on what might be in these guidlines (I
don't claim them all to be good so be happy to comment at them, or
propose your own, or just shoot me ;))

1 A packege should, without a good reason (like almost every
mathematician need the package almost all of the time), not use more
then X names in the global namespace. (You could ofcourse do import
Foo to get more things in the global namespace when using a certain
package very heavely).

2 All functionallity related to a package should always be accessible
by Packagename.[tab] or Packagename.Subpackage.[tab] or
Packagename.Subpackage.SubSubPackage.[tab] e.t.c.

3 Names of Subpackages should start with a capitalized letter, while
names of atributes and functions should not (or any other convenient
way to make an easy distinction between packages and functions)

4 Maybe some guidelines to encourage nice hierachical namespace
design.

5 Some sort of template hierachy to make the user interface
(espesially the [tab]) in sage feel the same through all packages.

5.1 For example categorical constructions like (fibred) sum, (firbred)
product, etc occur in all area's of mathematics, and could be grouped
in PackageName.CategoricalStuff (sorry for the lame name).

5.2 Another one is to make all object initialisation commands
available through something like PackageName.Init. using the current
graph implementation this addition would make the following two
statements equivalent
sage: graphs.CompleteGraph(6)
sage: Graph.Init.CompleteGraph(6)

Hope you don't mind the long tekst.
Maarten

[Craig Citro]

> That said, I'm not for some massive reorganization of
> the current global namespace, since that wold break a huge amount of
> existing code -- both in Sage and out (e.g., the examples at
> wiki.sagemath.org/interact).
>

I definitely agree that reorganizing and/or massively reducing the
global namespace would be a silly thing to do. However, I do think
things could be cleaned up a bit, and that certain things would
actually be *easier* to find if they were gathered into some
namespaces. Here are some thoughts:

1. I think a massively useful namespace would be databases.<tab>. As
it stands, we have various databases scattered throughout the global
namespace ... here are a few I found at random:

ConwayPolynomials
ClassicalModularPolynomialDatabase
zeta_zeros
cm_j_invariants

I've picked these somewhat at random, but I wanted to point out that
(1) the naming is (for good reason!) not at all uniform, and (2)
"Database" doesn't necessarily occur anywhere in the names. It would
be really interesting to be able to see all of the databases we have
at one fell swoop, I think. Also, it would be extremely helpful for
the person who wanted to see a database of modular polynomials, but
didn't realize that we labeled them ClassicalModularPolynomials.

2. I also think that there are cases where the global namespace is
getting a little polluted. Again, I was "tabbing around" at random, so
I don't think that these are necessarily the best examples, but I
think they're both good examples of places where we could probably
trim down the global namespace without losing anything serious.

First: David Joyner has done a lot of work to wrap various
functionality for computing special functions in Maxima & Pari in
sage. Tab completing, one finds things like:

sage: elliptic_<TAB>
elliptic_curves elliptic_ec elliptic_f elliptic_pi
elliptic_e elliptic_eu elliptic_kc

sage: spherical_<TAB>
spherical_bessel_J spherical_hankel1 spherical_harmonic
spherical_bessel_Y spherical_hankel2

Now, I have to admit, I had no idea what a lot of these were -- so I
went and read the source file sage/functions/special.py. At the top,
David has written an excellent description of what all these functions
are, and how they're all related. But you can only see it if you
happen to look at the comments at the top of the file! Maybe other
people disagree with me, but I would much rather have
elliptic_integrals.<TAB> give me a list, and have the nice
documentation that David wrote be the docstring for that module, so
that elliptic_integrals? would show these comments.

Second: I wonder if the constructors for some of the combinatorics
functions couldn't be given a common interface. For instance:

sage: SetPartitions
SetPartitions SetPartitionsIk SetPartitionsRk
SetPartitionsAk SetPartitionsPRk SetPartitionsSk
SetPartitionsBk SetPartitionsPk SetPartitionsTk

sage: Ja
JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

Now, I've never really looked at/used the combinatorics code at all,
so if what I'm about to say is totally off-base, just ignore me. But
looking at the constructors for the SetPartitions*, for instance, seem
to have the same signature. Would it be possible to replace them with
a single "SetPartitionsOfType" and take an extra argument that
specifies what type of partitions you're taking? This is similar to
what happens in the case of modular forms, where we essentially have
ModularFormsGamma0, ModularFormsGamma1, ModularFormsGammaH,
ModularFormsGamma0Eps, etc., all of which take similar inputs -- but
we have a global constructor (ModularForms) which takes the input and
calls off to the appropriate constructor.

3. Also, I think that moving a handful of things into namespaces, and
reducing the global namespace a little bit, could have two big
advantages for new users.

First, it's an easy starting point for a new user who wants to know
some of what Sage can do in a specific area. For instance, if I sit
down having never used Sage before, and I hit finance.<TAB>, I get a
sense for some of the things that might interest me, without having to
guess what I might get lucky with via tab completion, or what
something might be called.

Second, I think that a large global namespace is much more
disorienting to a new Sage user, *particularly* one who isn't an
experienced programmer, than many of us remember. For instance, the
SetPartitions* functions I pointed out before don't bother me
personally at all -- if I hit S<TAB>, they're visually grouped, and my
brain "knows" to ignore them if they're not the type of thing I'm
looking for. However, for the novice user who tries the same thing
(looking for, say, some Statistics functionality) is going to be
bombarded by a long list of functions, many of which seem to be about
something combinatorics-related. I'm not trying to say that we should
start severely pruning the global namespace, by any means -- I'm just
saying that a silghtly tidier global namespace is more approachable to
the novice user. (I'm not just hypothesizing here -- I know someone
who had exactly this experience, specifically with the case of
Statistics.)

-cc

[koffie]

+1 on craig, especially the 3th point.

ow I forgot to mention before, I also think that a massive
reorganization would be a bad thing to do since this would be big load
of work, and there are much better things that could get done in that
time. But motivating people to have the newly added stuff to be
organized in some sort of way, wich is uniform across all of sage, is
just a small effort, which could highly improve the user friendliness
of sage.

-Maarten

[Dan Drake]

On Tue, 02 Dec 2008 at 01:22AM -0800, Craig Citro wrote:
> Second: I wonder if the constructors for some of the combinatorics
> functions couldn't be given a common interface. For instance:
>
> sage: SetPartitions
> SetPartitions SetPartitionsIk SetPartitionsRk
> SetPartitionsAk SetPartitionsPRk SetPartitionsSk
> SetPartitionsBk SetPartitionsPk SetPartitionsTk
>
> sage: Ja
> JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp
>
> Now, I've never really looked at/used the combinatorics code at all,
> so if what I'm about to say is totally off-base, just ignore me.

I use the combinatorics code, and the SetPartitions* stuff bothers me. I
only use the regular SetPartitions code, and think the other ones can be
"put away". I like the "SetPartitionsOfType" idea.

Dan

--
--- Dan Drake <dr...@kaist.edu>
----- KAIST Department of Mathematical Sciences
------- http://mathsci.kaist.ac.kr/~drake

[Nicolas M. Thiery]

Hi!

Browsing back through my old e-mail, I just wanted to add a couple
notes.

Yes, as you suggest below, this indeed definitely should be reduced to
something like:

SetPartitions(..., type=["A",3])

> sage: Ja
> JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp

This one (together with SFA*, Macdonald*, kSchur*, ...) will be fixed
as soon as someone steps up to reorganize the symmetric functions
stuff as it is in MuPAD-Combinat. There, we had a single entry point:

S = SymmetricFunctions(field)
S.schur
S.jack(t).P
S.macdonald(t,q).Q
S.kSchur(3)

Volunteers?

And to answer another e-mail, the category framework could allow to
group a lot of the categorical constructions within a single entry
point: the category itself. For example, all the hom and much of the
tensor product code is there, and to start with:

FreeModules(QQ).hom_category()
FreeModules(QQ).tensor_category()

Cheers,
Nicolas
--
Nicolas M. Thiéry "Isil" <nth...@users.sf.net>
http://Nicolas.Thiery.name/

[Nicolas M. Thiery]

On Sun, Mar 08, 2009 at 09:32:05PM +0100, Nicolas Thiéry wrote:
> > sage: SetPartitions
> > SetPartitions SetPartitionsIk SetPartitionsRk
> > SetPartitionsAk SetPartitionsPRk SetPartitionsSk
> > SetPartitionsBk SetPartitionsPk SetPartitionsTk
>
> Yes, as you suggest below, this indeed definitely should be reduced to
> something like:
> SetPartitions(..., type=["A",3])

Now: http://sagetrac.org/sage_trac/ticket/5458

> > sage: Ja
> > JackPolynomialsJ JackPolynomialsP JackPolynomialsQ JackPolynomialsQp
> This one (together with SFA*, Macdonald*, kSchur*, ...) will be fixed
> as soon as someone steps up to reorganize the symmetric functions
> stuff as it is in MuPAD-Combinat. There, we had a single entry point:
>
> S = SymmetricFunctions(field)
> S.schur
> S.jack(t).P
> S.macdonald(t,q).Q
> S.kSchur(3)
>
> Volunteers?

Now: http://sagetrac.org/sage_trac/ticket/5457