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
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
wrote:
> On Thu, 14 May 2020 at 21:12, Aaron Meurer wrote:
> >
> > > Oscar, your idea looks helpful. It would resolve my concerns, but I'm
>
On Thu, 14 May 2020 at 21:12, Aaron Meurer 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
> >
> 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
> 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.
Maybe we should start being more careful about naming things with
preprended underscores, letting that explicitly define what is and isn't
public. This
Similar considerations potentially apply to other packages as well.
The __all__ attribute was added to 50 out of 138 __init__.py files
that didn't already have it. Obviously the top-level __init__.py is
the most significant though.
On Thu, 14 May 2020 at 20:23, Oscar Benjamin wrote:
>
> On Thu,
On Thu, 14 May 2020 at 19:57, Jason Moore 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.
I think that using
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
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
On Thu, 14 May 2020 at 18:46, Jason Moore 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
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?
Jason
moorepants.info
+01 530-601-9791
On Wed, May 13, 2020 at 4:43 PM Oscar Benjamin
wrote:
> On Thu, 14 May
On Thu, 14 May 2020 at 00:34, David Bailey wrote:
>
> On 13/05/2020 23:36, Jason Moore wrote:
>
> I had a look at the backwards incompatibilities.
>
> This one stood out:
>
> Submodule names are no longer imported with from sympy import *. They can
> still be imported directly like from sympy
On Wed, May 13, 2020 at 5:34 PM David Bailey wrote:
>
> On 13/05/2020 23:36, Jason Moore wrote:
>
> I had a look at the backwards incompatibilities.
>
> This one stood out:
>
> Submodule names are no longer imported with from sympy import *. They can
> still be imported directly like from sympy
> (Actually I've just realised this still happens on 1.6 because evalf
> is listed in __all__...)
Do we have tests for import *? We ought to test that certain things
are not included, like modules or non-sympy objects. It's less
necessary with __all__ and pyflakes checks, but maybe still a good
On 13/05/2020 23:36, Jason Moore wrote:
I had a look at the backwards incompatibilities.
This one stood out:
Submodule names are no longer imported with |from sympy import *|.
They can still be imported directly like |from sympy import core| or
accessed like |sympy.core|, or like
I've noticed in the past as well that it is not always easy to pick
out highlights. Typically the only obvious thing has been completed
GSoC projects. It may be prudent to just remove the section if we
can't find anything obvious to put there. It isn't as necessary as it
used to be since we now
On Wed, 13 May 2020 at 23:36, Jason Moore wrote:
>
> I had a look at the backwards incompatibilities.
>
> This one stood out:
>
> Submodule names are no longer imported with from sympy import *. They can
> still be imported directly like from sympy import core or accessed like
> sympy.core, or
This fixes a lot of issues like
https://github.com/sympy/sympy/issues/15536 and
https://github.com/sympy/sympy/issues/17626, where it was previously
impossible to reference names in a way you would expect, due to
submodule names that are the same as other submodules or as functions.
Another
I had a look at the backwards incompatibilities.
This one stood out:
Submodule names are no longer imported with from sympy import *. They can
still be imported directly like from sympy import core or accessed like
sympy.core, or like sys.modules['sympy.simplify'] for modules that share
names
Hi all,
I'm about to put up the release candidate for sympy 1.6. I think that
the release blockers are covered and the performance regressions
identified so far have been addressed. Thanks to all who have helped
with that.
I have been through the release notes and tried to extract what are
the
20 matches
Mail list logo
