*1. Replace use of "from sage.PAC.KAGE.all import ..." by more specific imports*
This pattern in our Sage library code blocks modularization. In particular, imports from sage.rings.all, sage.modules.all, sage.misc.all, sage.categories.all, sage.matrix.all must be avoided because sage.modules, sage.misc, sage.categories, sage.matrix are slated to become namespace packages (see https://trac.sagemath.org/ticket/32501). I have done this for sage.geometry in https://trac.sagemath.org/ticket/32534, but help with this throughout the Sage library is needed. *2. Do not import CLASS just to run an isinstance(..., CLASS); likewise, remove uses of is_CLASS functions* Instead, create abstract base classes that can be imported without pulling in the actual implementation classes (https://trac.sagemath.org/ticket/32414). I have done this in https://trac.sagemath.org/ticket/32566 for real/complex floating point fields. *3. Break up Cython modules that depend on several C/C++ libraries simultaneously* An example is sage.matrix.misc, which depends on both flint and mpfr. This is https://trac.sagemath.org/ticket/32433 (which needs help). Any contributions to these tasks are very welcome. For a roadmap of the modularization project, see https://trac.sagemath.org/ticket/29705 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5db4e1ec-d01e-4b8e-83eb-843ddb4749c6n%40googlegroups.com.
