> 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 --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
