Stop support for Python 3.9 #1316
Conversation
New major version are a good time to drop support for older versions. I thihnk 3.9 should not be an issue, I woudl argue for removal of 3.10 as well.
for more information, see https://pre-commit.ci
|
Why should we drop Python 3.9, since it has not reached EOL? |
|
Please read the description of the PR:
Also:
Waiting for EOL is not a good reason, EOL means that upsrtream have stopped supporting their package, in general it's better to stop before their EOL so that they can stop their support knowing they don't people in the dust. Saying you need to wait for EOL, is like saying "no it's fine you can use a deprecated feature, it has not been removed. |
|
Plus explicitly for 3.9, some test are flaky and annoying only on 3.9 |
|
These are still not valid reasons IMO. |
|
Meh, if you don't want that's fine. I find it a bit strange as for example main numpy is 3.11+, matplotlib is 3.10+ to lag more than 2 years behind and I have a hard time seing how someone that still python 3.9 can justify that they must have ipykernel 7+. It's not like dropping 3.9 support in 7.0 is still going to prevent 6.x to be installed...
This is factually false as IPython does it. Unless you do not consider IPython as a Jupyter project ? I think you are also adding maintenance burden to yourself and potentially pushing some contributors away. I personally only have so much free time I'm willing to invest to fix bugs on older Pythons, and there are also limited time I can justify to clients WRT python versions they don't use anymore. The "oh I can't do that because we still support 3.9", writing conditional code for older Python is becoming tiresome. Feel free to close. |
|
I'm just saying my opinion, thus not closing. |
Ah sure, well, but at the same time some project still advertise compatibility for Python 3.8 (jupyter_core, for example), and I don't think many project have discussed the issue, I'm guessing many rely on the maintainer tools default:
But notebook for example test on 3.9+
But this is again bumps because they had to (in my understanding), and I'd love for project to actually discuss python supported window instead of just doing it as late as possible when it's necessary because this is super painful. Without planning and a clear written rule it's sometime really hard to have discussion with clients. I would feel much better to know that ipykernel 7+ is Python 3.11+ only, than to have to say that yes, 7.0 to 7.6 is 3.9+, and 7.7 onward in 3.10+ and to be aware of that at the last minute. |
|
I feel this is something that has to be discussed at the Jupyter level, because one Jupyter project will affect many others, and this is especially true for ipykernel. |
|
Personally I am +1 on this. |
for more information, see https://pre-commit.ci
|
For what it is worth, I just got annoyed by 3.9, because and I really don't see why something released in 2025 need to support something that was release in 2020. There is still the 6.x branch for that. |
|
Can we maybe, just for 7.0 get the thought of @ipython/jupyterkernelteam ? |
|
I still have a mental image of Python 3.9 as a "recent" version, probably because it was a very nicely feature-packed release and subsequent releases were smaller in terms of features (literally, due to shortened development cycle, more on that later).
There is a precedent for releasing major versions (which we will need to support for a long time afterwards) with a requirement of using a Python version that already met its EOM but not EOL. For example, Python 3.7 was EOL on 2023-06-27 but:
Notably, Python release cadence has increased starting with Python 3.9 from once every 18 months to once every 12 months (https://peps.python.org/pep-0602/). One of the arguments for it was to allow more Linux distributions (case of Fedora is explicitly mentioned in the PEP) to synchronise their release schedule and avoid the shipped Python version from falling behind. I think this makes it easier to drop older versions because nowadays operating systems will ship (or offer) more recent versions. The downside is that dropping Python 3.9 will put downstreams in a position where they would need to test against multiple ipykernel versions as:
I find this a bit of a challenge for downstreams, because moving this fast means:
which is why I am against removal of Python 3.10 support. I think this is much less of problem for Python 3.9 with the current JupyterLab release cadence. CC @ccordoba12 for opinions. |
I'm confused of what the extra changes are here. In CI the python matrix will already install IPython 8.18.1 on 3.9, but 8.x (8.32 currently) on 3.10+ and latest on 3.11+ (which should) soon be 9.0). And that will be true for any direct or indirect (or conditional) dependencies as well. I'm genuinely confused on what it changes downstream, it's like literally the life of CI that versions of dependencies changes across CI matrix and why ipykernel would need to be different ? Do you mean that downstream may need to have conditional code based on IPykernel version ?
I'm confused as well here. I don't see why users can't use newer version of frontends if they can't update ipykernel? Don't/won't jupyterlab, server and all still work with ipykernel 6 ?
How is dropping support for something in ipykernel affects security issue in other projects ?
I mean we are not speaking of jupyter_client here – which I agree would have a much bigger impact. All of the above seem to be all the same point that were made for the "Drop python 2" transition; and the reason
Those are different arguments, and those are imho opinions, I can understand those but: I find the "weed won't have enough resources" also a double edge swords and also a bit of a straw man argument:
|
|
Yes, the misunderstanding and my poor points come from an implicit assumption that jupyterlab and other frontends will soon require the latest version of ipykernel. Of course, this does not need to be the case. Maybe my thinking here was biased by the failing downstream tests and this release being not backward compatible. In two points:
I agree someone needs to pay some extra maintenance cost and the decision to be made will just shift it between maintainers of ipykernel/users/maintainers of downstream. Some choices might allow to minimize the total cost.
Of course! I just explained what I thought was likely to happen, in a sense worse case scenario. It does not mean that this is a strong argument, or that I personally think this PR should not be merged, but I find value in exploring these scenarios to understand trade-offs. Spelling it out means others, like you, can correct errors in my reasoning. |
Ah with this assumption I understand, and if JupyterLab wants to pin ipykernel, then I agree with your points.
It seem that JupyterLab should anyway test kernels that do and do not support subshells, it's understandable that it's more work. Now this goes into a slight different direction of JupyterLab and Kernel vertical integration. Like if jupyterlab pins ipykernel, then I also expect older jupyterlab to not support ipykernel>7; in which case this is a vertical integration and we should likely merge back ipykernel and the server code into the same, or have releases in lockstep.
I understand, and I think 3.10 is on the fence, so I won't push for it. |
|
Responding to several comments at the same time:
I don't see this as a good enough reason to drop support for 3.9 for users (see my next point).
The problem with dropping old versions is, in my opinion, the impact it has on users that started research projects two or three years ago. At that time Python 3.9 was still relatively recent, so it was a valid choice. And since it takes something between one to three years to publish a paper, you usually don't change your Python env in that time to not risk breaking your code. You could think that's a bit farfetched, but I'm talking from my own experience here. I finished my PhD a few years ago and I was still using an env I created in 2016 or so for one paper, to get results for another, related paper in 2021! For me it was easier to do that rather than updating the env and dealing with the many minor and major changes in more recent versions of Numpy, Pandas, Matplotlib, Seaborn, NetworkX, etc, that broke my code. But I was able to update Spyder/IPython/IPykernel to get bugfixes for them (of course, their code is, for the most part, orthogonal to the scientific libraries one). That's why we in Spyder support the last Python version that hasn't reached EOL (I think users understand easily that we can't support versions after their EOL). Furthermore, it's a not big deal for us to do that because we're not a compiled library and, in my opinion, most Python 3.7+ versions are quite similar except for annotations (which we don't use heavily).
I think the branches are quite different at this point, so it'd be difficult to do backportings.
Actually, we still test on Python 3.8 but only with pip packages and will continue to do so until Spyder 6.1.0 is released (we don't drop support for Python versions in bugfix releases and when we released 6.0, 3.8 hadn't reached EOL).
I also agree with @krassowski: being a pure Python package, IPython could still support Python 3.10. I mean, I think NEP 29/SPEC 0 is a good thing for compiled libraries because it reduces the effort of creating wheels for a lot of Python versions. But it's not something pure Python packages should adhere strictly to (even some important compiled libraries such as PyZMQ still support Python 3.8).
Sure, but it'd be much easier, for instance, to move to support IPykernel 7 only at some point in the future, and keep supporting Python 3.9. Instead, what we've done in the past is to add workarounds for specific IPykernel versions that added/removed this or that so that we can keep supporting older Python versions.
IPykernel is more important for us than Jupyter client. Our Variable Explorer, debugger, Matplotlib integration and several other features are based on it. But I understand it's different for Jupyter.
Not in my experience, sorry. It's a little bit more work for us, but not something that requires constant attention and many resources (otherwise we were not doing it).
But the main argument you've mentioned so far for dropping Python 3.9 here is a nuisance with annotations. As I said at the beginning, I don't think that's strong enough to justify it. |
Well IPython had to deal with many things, worst of which are
Which make the code extremely convoluted to understand and update correctly in all the cases. Like anything sure I could support it, and the annoyance of sending a pull-request to IPython that pass everywhere – except on 3.10 – and need one more iteration and conditional import and installing typing-extension, and ah no, actually typing extension or typeshed don't have the right types, was regularly taking more time that actual features or fixes. (to be fair 3.9->3.10 had way less annoying changes than 3.10 -> 3.11) |
New major version are a good time to drop support for older versions. I thihnk 3.9 should not be an issue, I woudl argue for removal of 3.10 as well.