I agree, and this is why we have a deprecation policy. https://github.com/sympy/sympy/wiki/Deprecating-policy. In some cases, it is very difficult to do a deprecation due to technical limitations, and we just have to make the breaking change, and I think this is an instance of that.
We also have to balance usability, and improve that where we can, even if that means breaking API. In this case, if a user uses SymPy in an interactive way (anything that does "from sympy import *") they will see things like "add" in the namespace, and might assume that is a function. But "add" (in SymPy 1.5.1) is a submodule. Furthermore, we don't want users to use add even as a submodule, because anything on the "add" module is either a public function that is already in the public namespace (like Add), or a private function. A big part of keeping backwards incompatible changes to a minimum is to have a clear distinction between what is public API and what isn't. That way we can improve SymPy by refactoring the non-public APIs without breaking users. This change is an improvement in that direction, since we don't want submodules to be part of the public API. Aaron Meurer On Thu, May 14, 2020 at 12:57 PM Jason Moore <moorepa...@gmail.com> wrote: > > Is it possible to give a blanket deprecation warning if anyone does an import > with a `*`? It could warn the user that functionality will change in the next > version such that modules are not accessible via star imports. > > As more a user than developer of SymPy, I think we should have a very high > standard for deprecation. As one of the primary OSS CAS libraries there is a > lot of potential code to break in the wild and lots of users to frustrate. > From years watching students (as well as myself) get frustrated due to code > breaking from software upgrades, I think this is important. We need to be > better than Mathematica and Matlab at this to retain and grow users, and they > are really really good about not breaking existing code. As developers, these > changes may seem trivial, but they are often huge hurdles to users. > > Jason > moorepants.info > +01 530-601-9791 > > > On Thu, May 14, 2020 at 11:39 AM Oscar Benjamin <oscar.j.benja...@gmail.com> > wrote: >> >> On Thu, 14 May 2020 at 18:46, Jason Moore <moorepa...@gmail.com> 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 sympy+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxT7Ji6Y4FE5UN%2BKwQmDs7zwNFt65Exg2r771Hr26SHGTA%40mail.gmail.com. > > -- > 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 sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAP7f1AjnrzOEOuk7PNo9sFoO-a4WtJEtN7dUuevLpQEnp7PoKw%40mail.gmail.com. -- 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 sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Ks7bnZQKzxgkFgHv62%3Deu%2B35d9czKVZz5%3Dc2wD2y6DwA%40mail.gmail.com.
