I'm going to push a second release candidate with this change and also
the fix for this:
https://github.com/sympy/sympy/issues/19326
Another import issue has occurred to me though which is that the ode
module has now become a package so the ode.py file was moved from
sympy/solvers/ode.py to sympy/solvers/ode/ode.py. The "public" names
(as documented) are imported into sympy/solvers/ode/__init__.py but
these are a small subset of the total names available when doing
from sympy.solvers.ode import *
This doesn't just apply to star-imports and __all__ because someone
might be doing something like:
from sympy.solvers.ode import solve_ics
even though constant_simp is not listed as a "user" function in the
documentation:
https://docs.sympy.org/latest/modules/solvers/ode.html
Attempting to import solve_ics like that will give an ImportError in 1.6.
Most of the things importable from the ode module are actually from
other places in sympy and are just used internally in the module. Some
of the things are defined in the ode module and are not importable
from anywhere else. Most of those are internal functions that are not
really usable outside of dsolve but there are some that someone might
want to use e.g. checksysodesol, classify_sysode, solve_ics...
The full list of names that is importable from the ode module in 1.5.1
but not from the ode package in 1.6 is:
Add
And
AppliedUndef
AtomicExpr
BooleanAtom
BooleanFalse
BooleanTrue
Derivative
Dummy
Eq
Equality
Expr
Function
I
Integral
Matrix
Mul
NaN
Not
Number
Order
Piecewise
Poly
PolynomialError
Pow
Rational
RootOf
S
Subs
Symbol
Tuple
Wild
airyai
airybi
atan2
besselj
besselsimp
bessely
cancel
cbrt
check_linear_2eq_order1
check_linear_2eq_order2
check_linear_3eq_order1
check_linear_neq_order1
check_nonlinear_2eq_order1
check_nonlinear_2eq_order2
check_nonlinear_3eq_order1
check_nonlinear_3eq_order2
checksol
checksysodesol
classify_sysode
collect
collect_const
conjugate
constant_renumber
cos
cse
default_sort_key
defaultdict
degree
diff
div
division
equivalence
equivalence_hypergeometric
exp
expand
expand_mul
eye
factor_terms
factorial
fraction
gcd
get_numbered_constants
hyper
im
integrate
is_sequence
islice
iter_numbered_constants
iterable
lcm
lie_heuristic_abaco1_product
lie_heuristic_abaco1_simple
lie_heuristic_abaco2_similar
lie_heuristic_abaco2_unique_general
lie_heuristic_abaco2_unique_unknown
lie_heuristic_bivariate
lie_heuristic_chi
lie_heuristic_function_sum
lie_heuristic_linear
lie_heuristics
log
logcombine
match_2nd_2F1_hypergeometric
match_2nd_hypergeometric
match_2nd_linear_bessel
numbered_symbols
ode_1st_exact
ode_1st_homogeneous_coeff_best
ode_1st_homogeneous_coeff_subs_dep_div_indep
ode_1st_homogeneous_coeff_subs_indep_div_dep
ode_1st_linear
ode_1st_power_series
ode_2nd_hypergeometric
ode_2nd_linear_airy
ode_2nd_linear_bessel
ode_2nd_power_series_ordinary
ode_2nd_power_series_regular
ode_Bernoulli
ode_Liouville
ode_Riccati_special_minus2
ode_almost_linear
ode_factorable
ode_lie_group
ode_linear_coefficients
ode_nth_algebraic
ode_nth_linear_constant_coeff_homogeneous
ode_nth_linear_constant_coeff_undetermined_coefficients
ode_nth_linear_constant_coeff_variation_of_parameters
ode_nth_linear_euler_eq_homogeneous
ode_nth_linear_euler_eq_nonhomogeneous_undetermined_coefficients
ode_nth_linear_euler_eq_nonhomogeneous_variation_of_parameters
ode_nth_order_reducible
ode_order
ode_separable
ode_separable_reduced
ode_sol_simplicity
odesimp
oo
ordered
pdsolve
posify
powdenest
powsimp
print_function
range
re
rootof
roots
roots_quartic
separatevars
series
sift
simplify
sin
solve
solve_ics
sqrt
string_types
sub_func_doit
symbols
sympify
sysode_linear_2eq_order1
sysode_linear_2eq_order2
sysode_linear_3eq_order1
sysode_linear_neq_order1
sysode_nonlinear_2eq_order1
sysode_nonlinear_3eq_order1
tan
terms_gcd
trigsimp
vectorize
wronskian
zeros
zoo
--
Oscar
On Fri, 15 May 2020 at 01:37, Jason Moore <[email protected]> wrote:
>
> Thanks Oscar. I'll look at it later tonight to give you a review.
>
> Jason
> moorepants.info
> +01 530-601-9791
>
>
> On Thu, May 14, 2020 at 3:45 PM Oscar Benjamin <[email protected]>
> wrote:
>>
>> On Thu, 14 May 2020 at 21:12, Aaron Meurer <[email protected]> wrote:
>> >
>> > > Oscar, your idea looks helpful. It would resolve my concerns, but I'm
>> > > not sure how to evaluate if that is worth doing. My opinion is that if
>> > > the effort to deprecate isn't extreme, then we should do it. What
>> > > "extreme" is defined as, is certainly debatable.
>> >
>> > I may be wrong on this, but I don't think Oscar's idea would actually
>> > work. The issue is that there's no way to tell the difference between
>> >
>> > from sympy import *
>> > core
>> >
>> > and
>> >
>> > from sympy import core
>> > core
>> >
>> > where the latter still works and should work. We could make it not
>> > work, but it's expected Python behavior to be able to import
>> > submodules like this.
>>
>> I've opened a PR:
>> https://github.com/sympy/sympy/pull/19316
>>
>> The PR adds back all the submodules wrapped in an object that emits a
>> warning when accessed e.g.:
>>
>> In [1]: from sympy import add
>>
>> In [2]: add.Add
>> /Users/enojb/current/sympy/sympy/sympy/__init__.py:653:
>> SymPyDeprecationWarning:
>> importing sympy.core.add with 'from sympy import *' has been
>> deprecated since SymPy 1.6. Use import sympy.core.add instead. See
>> https://github.com/sympy/sympy/issues/18245 for more info.
>>
>> deprecated_since_version="1.6").warn()
>> Out[2]: sympy.core.add.Add
>>
>> I left out core which can not be included in a backward compatible way
>> without failing to fix the broken behaviour that from sympy import
>> core doesn't give the package.
>>
>> This is similar to what scipy recently did:
>> https://github.com/scipy/scipy/pull/10290
>>
>> Top-level packages like printing, polys etc are all just listed in
>> __all__ (and not deprecated).
>>
>> The only names not importable by from sympy import * in the PR that
>> were previously importable in 1.5 are:
>>
>> SYMPY_DEBUG
>> core
>> physics
>>
>> Those could also be added. In the case of core the reason is above.
>> For physics it's because adding it means importing it even during a
>> plain "import sympy" which otherwise wouldn't happen. SYMPY_DEBUG
>> seems obviously internal to me.
>>
>> --
>> 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/CAHVvXxS8ZLoBzercBDypJ-b4Tk3eWRYFULVEvOjiYs8b%3DLFNCg%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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sympy/CAP7f1AjefdtOi1qpitdJmL5snooWdOjwqczVLu%3D1Xpzy%2BhA7cQ%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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/CAHVvXxRWPY42mb60jb2w9ATQLzySLAA-_gwTRz1bmO81WfCvZw%40mail.gmail.com.
