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.