What versions of Python does python-flint support? A potential issue could be if python-flint follows SPEC 0 but SymPy supports older Python versions, then SymPy would necessarily have to also support older versions of python-flint, even if we might otherwise be able to avoid that by doing releases in tandem.
Aaron Meurer On Wed, Apr 16, 2025 at 6:22 AM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Tue, 15 Apr 2025 at 18:40, Aaron Meurer <asmeu...@gmail.com> wrote: > > > > That's been our policy in the past > > https://github.com/sympy/sympy/wiki/Python-version-support-policy. We > > definitely should just decide on a policy and stick with it. Then we > > won't have to discuss it every time we do a release. The main downside > > of supporting Python versions up to EOL is that Python has a faster > > release cadence now, meaning that when we do this we have to support > > up to 5 different Python versions at once (3.9, 3.10, 3.11, 3.12, and > > 3.13). When that policy was written the cadence was slower and only > > meant supporting 3 versions at once (not counting Python 2). > > I think this is why spec 0 says what it does. It was decided to > support 3 Python versions when Python versions were released every 18 > months which meant supporting all non-EOL Pythons. Then CPython > decided to go to a 12 month release schedule and moved to supporting 5 > versions concurrently rather than 3. > > Supporting many versions like this is not such a problem for a pure > Python package like SymPy but for e.g. NumPy or python-flint this > means producing almost twice as many binaries and testing twice as > many combinations. The most recent release of python-flint has > binaries for the Cartesian product of > > CPython: 3.11, 3.12, 3.13, 3.13t (free-threaded) > > OS/Arch: > MacOS x86_64 > MacOS ARM > Windows x86_64 > ManyLinux x86_64 > ManyLinux ARM > > That's 4*5 = 20 wheels with each at 10MB meaning that a full release > is 200MB of wheels on PyPI: > https://pypi.org/project/python-flint/#files > > Supporting all non-EOL Python versions plus free-threaded would > increase the first part in future to: > > CPython 3.13, 3.13t, 3.14, 3.14t, 3.15, 3.15t, 3.16, 3.16t, 3.17, 3.17t > > Then it is 10*5 = 50 wheels making 0.5GB per release. PyPI has a limit > of 10GB for all releases of a project: > https://github.com/pypi/warehouse/blob/8060bfa3cb00c7f68bb4b10021b5361e92a04017/warehouse/forklift/legacy.py#L70-L72 > > At 0.5GB per release python-flint would exceed the file size limit > after 20 releases and would then need to start deleting older > releases. > > Another thing on the horizon is Windows ARM and then there are also > other things like musllinux and so on that e.g. numpy provides wheels > for: > https://pypi.org/project/numpy/#files > Looks like NumPy has 50 wheels per release just for Python 3.10-3.13 > and 3.13t already. > > On top of 50 platforms to produce binaries then you can imagine > needing to test all of those with say a range of different versions of > something else like different SciPy versions or something. > > Of course these file size limits and the combinatorial explosion of > platforms and ABIs are not directly relevant to SymPy but it shows why > other scientific Python packages don't want to say "let's just support > every non-EOL Python". > > What matters for SymPy though is how its version support lines up with > other packages because as I said in the start the problem is that any > library that depends on SymPy without using an upper cap like > sympy<=3.13 is potentially broken if a new SymPy release goes out for > older Python versions that the dependent library no longer supports. > > There is a general suggestion that Python packages should not use > upper cap version ranges like sympy<=3.13 but that only works if there > is some synchronisation around the supported Python versions. > Effectively it is the minimum Python versions required by each package > that acts as an implicit upper cap between e.g. SymPy and anything > else that depends on SymPy as well as all the things that SymPy > implicitly depends on like NumPy etc. If SymPy didn't specify a > minimum Python version then each new release would probably break > other packages for people using older Python versions. > > > At the same time, I'm not aware of new Python features that we really > > wish we could be using but can't as long as we keep supporting older > > versions. Are there examples of this? > > There aren't many new features that are needed in the sense that older > versions have to be dropped in order to get those features. Typically > this only happens for new syntax and recently I think all syntax > changes have been related to typing e.g. the syntax here would be > useful but cannot be used without dropping Python 3.11: > https://peps.python.org/pep-0695/ > > The question is not how hard or easy it is for SymPy to support many > Python versions or whether there are new features that would benefit > SymPy though. It is really about the fact that pushing a new SymPy > release out to an old version of Python risks breaking things that > depend on SymPy. If most other things follow SPEC 0 then it is better > that SymPy does as well but I'm not sure that is the case. > > Anyway for now I think we are all agreed that SymPy 1.14 should stick > with 3.9 upwards. > > -- > 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 visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTnD59ECAWDXf1GuO-73OUHfSZ30vtvkSECvoyUHTVRjg%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 visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KHCK7mwBbpJBDbfaLy8N0TH%3DnxuLOze8zdoV4Ex8B3MQ%40mail.gmail.com.
