On Thu, 14 May 2020 at 18:46, Jason Moore <[email protected]> wrote: > > These all seem like good reasons to make the change. Did users get a > deprecation cycle for the change? i.e. if I mport one of the affected imports > in 1.5 I get a deprecation warning?
No. I'm not sure how you could get a deprecation warning. For example we would have to make it so that e.g. from sympy import core still gives the module object for sympy.core.core but wrapped in some kind of object that gives a deprecation warning when you access it. Really though from sympy import core should be the expected way to import the sympy.core package analogous to `import sympy.core as core` (It would be better if that was the only way to do submodule imports in Python because it removes this ambiguity). In SymPy 1.5.1 there are 971 names imported by `from sympy import *`. In 1.6 there are 874. There have been 8 names added and 105 removed. The removed names are: SYMPY_DEBUG add algebras array assumptions basic bivariate boolalg cache calculus codegen combinatorics common compatibility concrete conditionset containers contains convolutions core coreerrors cse_main cse_opts curve decorators dense deprecated deutils discrete ellipse entity epathtools exceptions expr expr_with_intlimits expr_with_limits expressions exprtools external factor_ facts fancysets function functions generate geometry gosper immutable index_methods indexed inequalities inference integrals interactive line logic manualintegrate matrices meijerint mod mul multidimensional multinomial multipledispatch ntheory numbers ode operations ordinals parabola parsing partitions_ pde physics plane plotting point polygon polys polysys power powerset primetest printing products recurr relational release residue_ntheory rules sets singleton singularityfunctions solvers sparse sparsetools strategies summations symbol tensor transforms traversaltools trigonometry util utilities Some of these are top-level packages e.g. sympy.physics. I don't see how we can make "from sympy import *" give something different for physics than what "from sympy import physics" would give so I can't see how we could give a deprecation warning for one case but not the other. Others are subpackages and submodules e.g. add is there because it is a top-level module in core and sympy's __init__.py used to do "from .core import *". Doing "from sympy import add" gives an ImportError in 1.6. We could make "from sympy import add" return a proxy object that emits a deprecation warning each time you try to access it. I don't see why anyone should be depending on this though given that there is no documentation specifying that you can do "from sympy import add" and no one outside of sympy would be interested in accessing the add module directly because the significant output from the module is Add which you can import from sympy directly (and is documented). As an side we really should stop putting everything up to the top-level sympy namespace. There are far too many names there and importing sympy is slow because it isn't possible without importing every submodule. A recent bug report pointed out that it takes minutes to import sympy in brython. -- Oscar -- You received this message because you are subscribed to the Google Groups "sympy" 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/sympy/CAHVvXxT7Ji6Y4FE5UN%2BKwQmDs7zwNFt65Exg2r771Hr26SHGTA%40mail.gmail.com.
