On Mon, Apr 26, 2010 at 5:10 AM, Simon King <simon.k...@nuigalway.ie> wrote: > Hi David! > > On 26 Apr., 13:49, David Roe <r...@math.harvard.edu> wrote: >> Marshall's right that you need to change where the import comes from, but >> you actually want >> from sage.rings.finite_rings.constructor import FiniteField >> >> The class in sage.rings.finite_rings.finite_field_base is the base class, >> whereas FiniteField in constructor is the UniqueFactory that makes finite >> fields. > > So far I tried to name the module explicitly in the import statement. > But probably it is easier to import from sage.all when possible. Is > this considered good praxis? I guess that this is more robust against > changes in the underlying modules when upgrading sage.
Yes, you should definitely import from sage.all or sage.rings.all whenever possible, instead of directly from some module. The API of the "all.py" files are much more stable (especially the higher they are in the directory structure). I'm torn -- I'm not sure this should be subject to the deprecation policy (as Jason asks), because it's really not an issue of breaking what is meant to be the external API of Sage (=sage.all). William > > Best regards, > Simon > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- William Stein Professor of Mathematics University of Washington http://wstein.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
