Statement on pytensor's python support/release schedule #1803
-
|
(follow up from conda-forge/pytensor-suite-feedstock#190) In the current documentation, I cannot find any details on when pytensor chooses to drop support for specific python versions. For example, in #1253, python 3.10 was dropped around 4 years after python 3.10 was released. If one follows https://scientific-python.org/specs/spec-0000/ - then I would have expected this support to have dropped in 10/2024 (but this wasn't the case), and expect python 3.11 support to be dropped in the remaining few days this month. Could the core team clarify their stance wrt to pytensor for dropping or supporting python versions -- and put this in the documentation somewhere? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
Copying (and slightly extending) my reply from: conda-forge/pytensor-suite-feedstock#190 (comment) We follow the Scientific Python schedule loosely, we don't rush to drop support on the exact day. Sometimes a major release is only made a few months later, sometimes it's just not a priority. We will NOT drop support before schedule. There's a benefit to dropping support though, which is we can start using new python syntax/ features like match statements, which would have to wait indefinitely before adoption. Also dependencies like numpy/scipy may introduce changes over distant releases that we would need to "massage" so users of both new and old versions see the same behavior. A recent example was numpy 2.0x which introduced changes in default behavior like unique and casting rules. We're happy to consider special requests on a per version basis, but would ask for consideration on the potential developer burden. |
Beta Was this translation helpful? Give feedback.
-
To clarify my comment in the issue linked above, I agree that this is the right approach. (My disagreement would only be with rushing to drop support with no concrete motivation from the developer burden side.) |
Beta Was this translation helpful? Give feedback.
-
|
I edited that specific sentence because I thought it was redundant. But happy for it to survive quoted (and in the edit history ofc) |
Beta Was this translation helpful? Give feedback.
-
|
Just to add additional context (minorly edited my original post) -- when a non-core package drops support while the other core packages haven't fully provided support for a future python (e.g. 3.14) because I guess this is not pytensor's problem per-se, but conda is a pretty big distribution ecosystem (I am a bit biased here) and unless one explicitly has a 3.14 variant for all subpackages... |
Beta Was this translation helpful? Give feedback.
-
|
Right, but I think that this situation is fairly typical. Dependency management is hard, and you always have to hope that your dependencies are satisfiable. Supporting 3 versions is much better than 0 versions, no? 😉 |
Beta Was this translation helpful? Give feedback.
Copying (and slightly extending) my reply from: conda-forge/pytensor-suite-feedstock#190 (comment)
We follow the Scientific Python schedule loosely, we don't rush to drop support on the exact day. Sometimes a major release is only made a few months later, sometimes it's just not a priority. We will NOT drop support before schedule.
There's a benefit to dropping support though, which is we can start using new python syntax/ features like match statements, which would have to wait indefinitely before adoption.
Also dependencies like numpy/scipy may introduce changes over distant releases that we would need to "massage" so users of both new and old versions see the same behavior. A recent ex…