On Fri, Nov 22, 2013 at 10:23 AM, Volker Braun <vbraun.n...@gmail.com> wrote: > There is some value to have often-used things in the global namespace; Sage > integers should always be ZZ and not just rings.Integers.
+1 This was in particular one of the things I changed from the design of Magma, where you *have* to type out IntegerRing() or Integers(), unless you have a custom startup file. Not having common shortcuts like ZZ in the global namespace of Magma was a conscious design choice they made, which I didn't agree with. In retrospect, I think it's fine having ZZ. > * Remove obscure constructors from globals at some later time, err on the > safe side for what is "obscure"... Maybe we could have a criterion to decide what "obscure" is and some examples? For example, if a typical ending first year pure math *graduate student* is unlikely to have heard of the object, then it is obscure. Thus RationalField(), QQ, matrix, Graph, primes, are clearly not obscure, whereas dimension_cusp_forms which I put in the global namespace, when I was the only user of Sage, is definitely obscure, as (sadly) is ModularSymbols, which is also "obscure". A more interesting edge case is EllipticCurve, which I would argue should remain in the global namespaces... > > * In the future, do not add new factory functions to the global namespace if > there is a better place > > > > > > On Friday, November 22, 2013 8:09:18 AM UTC-5, Nathann Cohen wrote: >> >> Hellooooooo everybody ! >> >> I just created ticket that adds a new codes.<tab> object to Sage gathering >> all codes that Sage can build, the same way that we already have such >> objects for groups/graphs/designs/matroids and perhaps others. >> >> Basu wondered if it made sense to keep all constructors in the global >> namespace at the same time. Because right now, you can do both >> >> sage: HammingCode(3,GF(2)) >> Linear code of length 7, dimension 4 over Finite Field of size 2 >> >> and >> >> sage: codes.HammingCode(3,GF(2)) >> Linear code of length 7, dimension 4 over Finite Field of size 2 >> >> So, well. Do we keep them, do we remove them ? I'm all for removing them >> from the global namespace too, as they can all be found through the >> codes.<tab> object anyway. What do you think ? >> >> And I guess we can ask ourselves the same question for groups too. And >> designs. >> >> Graphs behave well already :-P >> >> Have fuuuuuuuuuuuuuuuuuuuuun ! >> >> Nathann >> > -- > 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 sage-devel+unsubscr...@googlegroups.com. > To post to this group, send email to sage-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
