+1 to removing them from the main namespace (with appropriate deprecation period).
When we designed the matroid code, keeping the namespace clean was an important goal for me. So we only have "Matroid" and "matroids" in there, and I expect it'll stay that way. I can see no reason to have individual codes and designs litter the namespace. Groups, rings and fields are a muddier issue, because they're so widely used. --Stefan. On Friday, November 22, 2013 9:53:33 AM UTC-5, P Purkayastha wrote: > > On 11/22/2013 09:34 PM, John Cremona wrote: > > On 22 November 2013 13:31, Nathann Cohen <nathan...@gmail.com<javascript:>> > wrote: > >> Hellooooooo !! > >> > >>> Backwards compatibility issues? > >> > >> Well, we can deprecate stuff for a start. And the message could say > "What > >> you are looking for moved to a different place ! It's larger, there is > a lot > >> of light and a comfy couch. Come join us !" > >> > >>> I have a lot of code where I would > >>> not want to change every NumberField(...) to fields.NumberField(...) > >>> and similarly with QuadraticField() and CyclotomicField(). Is this > >>> just a question of scale, i.e. those are almost all the special field > >>> constructors while there are lots and lots of codes? > >> > >> Hmmm... There is no "fields.<tab>" object in the version of Sage I run, > so I > >> don't get your question O_o > > > > You are right -- but I thought that your proposal was that there > > should be, instead of what there is now. > > > > My reason for suggesting this change (at least for the sage/coding) is > so that the codes are more easily discoverable. > > Right now, if I want a specific code, say Hamming code, I have to > remember "oh.. the name of the code is Hamming, so it probably starts > with Hamming in Sage too. Oh great! That works! Hamming<tab> gives > HammingCode. Let's try LDPC<tab>.. nothing, ok.. maybe.. ldp<tab>, nope. > Low<tab>, nope." And then I will have to go around searching through the > documentation and realize that ldpc codes are not there in Sage. > > With the codes.<code> introduced by Nathann, it can easily be checked > what codes are there - by simply doing a codes.<tab>. Once this ticket > is in place, it would be in fact nice to not have all these codes also > in the global namespace. Having them in both places is a duplication, > and might even be confusing to a new user. It is not for now, but rather > for later - as the components inside Sage themselves grow in size with > new constructions they will be better organized if they are under the > general names and discoverable via tab completion beyond that. > Temporarily, one's programs may not run or may give deprecation errors. > Over the long term everyone should benefit from a neatly organized > namespace. > > Just my opinion. :) > > - basu. > > -- 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.
