On Tue, 15 Apr 2025 at 18:40, Aaron Meurer <[email protected]> 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/CAHVvXxTnD59ECAWDXf1GuO-73OUHfSZ30vtvkSECvoyUHTVRjg%40mail.gmail.com.
