Hi all,

It is past time that a new release of SymPy is needed. Let's get SymPy
1.13 out ASAP.

I had been meaning to put out a bugfix release of SymPy 1.12.1 because
of a few things that have been fixed since SymPy 1.12 but it didn't
happen. In particular compatibility with Python 12's ast module for
parsing string expressions was fixed and a few other small things.
Also some changes were recently made for compatibility with NumPy 2.0
which is probably going to be released in a few months but we should
get out a SymPy release first.

There are of course also many other improvements since SymPy 1.12. You
can see the release notes here:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13

I've created a release issue here to track releasing 1.13:
https://github.com/sympy/sympy/issues/26169

Please say if there are any release blocker issues or other things
that should be resolved before the release.

Here is one from me:

After the 0.6.0 release of python-flint I would like to get this PR
merged to use Flint for polynomials and matrices over GF(p) as well as
ZZ and QQ:
https://github.com/sympy/sympy/pull/25940

A larger issue to be resolved is how exactly SymPy should use
python-flint. Currently with the SymPy master branch it is necessary
to set an environment variable SYMPY_GROUND_TYPES=flint to get SymPy
to use python-flint. That is not how it works with gmpy2 though, which
will just be picked up automatically when it is installed without the
need to set an environment variable.

In principle the use of python-flint should not change the behaviour
of SymPy at all except that some particular things are made a lot
faster. Currently those things are:

- Univariate polynomials over ZZ, QQ (and GF(p) if the PR above is
merged). This means various functions like `factor`, `gcd` etc are
faster.
- Algebraic extension fields like QQ.algebraic_field(sqrt(2)) since
their ANP type uses Flint's univariate polynomials as well now.
- The dense format of DomainMatrix when the domain is ZZ, QQ (or GF(p)
if the PR above is merged).

These changes are very particular about what exactly is or is not made
faster but some particular operations are made much faster and for
others it makes no difference. In future Flint's multivariate
polynomials will be used and that will end up having a more noticeable
impact on the speed of higher-level operations for most end users.

The question is whether to be conservative about making use of
python-flint by requiring an opt-in environment variable like this.
There are two possible downsides for a given user if SymPy starts
using python-flint automatically:

1. It is not yet that widely tested by many different people on
different computers etc so it is possible that there are unknown bugs.
2 I expect that many things will change in python-flint over the next
few years. It is possible that a SymPy release of 1.13 now will not be
fully compatible with say a future release of python-flint in a few
years time.

Note that python-flint is not as widely used or installed as SymPy by
a long way. I doubt that there are many people who just happen to have
python-flint and SymPy installed and would then be surprised that
SymPy started using python-flint. Probably most of the time the fact
that someone has installed both packages together is because they want
SymPy to use python-flint.

I think that probably the right way to do this is just for SymPy to
use python-flint by default if it is installed but with an almost
exact version check like `python-flint == 0.6.x` because `0.6.0` is
the minimum version needed for the PR above but also the maximum
version that has been tested before release. It would be good to allow
the flexibility to have `0.6.1` though in case there is a small bugfix
release of python-flint. Over time if things seem more stable then we
could relax that version constraint. The environment variable could
still be used to override the version check but the default if no
environment variable is set should just be to use python-flint but
only the expected 0.6.x versions.

Does anyone have any thoughts on how exactly to do this?

--
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/CAHVvXxTb9K-2uLsCCzfZGHK9HmFekM1LKHQJYVbys60aPr25pg%40mail.gmail.com.

Reply via email to