bbangert / beaker

WSGI middleware for sessions and caching
https://beaker.readthedocs.org/
Other
517 stars 147 forks source link

RFE: drop python<=3.7 support #239

Closed kloczek closed 4 months ago

kloczek commented 4 months ago

Python 2.x has been EOSed more than 4 years ago and python 3.7 Jun last year. https://endoflife.date/python

IMO it would be good to create 1.x branch and commit on that branch only critical fixes and start working on remove first all python 2.x support and than clean the code do drop python<=3.7. First new stable release can be like 2.0.0. pyupgrade --py38-plus command generated +28KB patch on top of which is possible to make probably another ~20KBmanual changes.

PS. Sep this year will be EOSed python 3.8 but if all code up to then will be cleaned remove python 3.8 support can be almost instantly generated using pyupgrade --py39-plus commend.

amol- commented 4 months ago

Install base of Python 3.7 and 3.8 constitutes >50% of all installed python versions (see https://w3techs.com/technologies/history_details/pl-python/3 for example) and specifically to beaker, Python 2.7 is still the 4th most used version with 3.7 being the 3rd: https://pypistats.org/packages/beaker

Beaker should follow the demand from its users, not force them to upgrade unless it's necessary. Especially since the overhead of maintaining backward compatibility hasn't been much so far. Over time we will phase out unused versions.

kloczek commented 4 months ago

This RFE i snot about abandon support of any of those python versions. 😄 It is about branch current tree and backport only critical changes to be able keep on master 100% c;lean code supporting only not EOSed python versions 😋 Benefit of that is that should allow remove and/or clen a lot of code which would fully compensate devel man/hours spend on backporting critical changes. Only this and nothing more ..

amol- commented 4 months ago

I'm not convinced that it would compensate the labour necessary to maintain two branches, practically rewriting everything twice, especially as the codebase starts to diverge and thus changes might not easily merge anymore. Plus the initial effort at upgrading the codebase (and no, pyupgrade --py39-plus is not enough if you want to actually take benefit on the new patterns that are available in newer versions instead of just changing set(...) to {...} which is little more than syntactic sugar)

kloczek commented 4 months ago

Please .. I'm not talking about create two branches. I'm talking about one branch and backport only critical fixes.

pyupgrade --py39-plus is not enough if you want to actually take benefit on the new patterns that are available in newer versions instead of just changing set(...) to {...} which is little more than syntactic sugar)

Please try to have closer look closer on what is possible to remove more after that automatic filtering all code.

amol- commented 4 months ago

Please .. I'm not talking about create two branches. I'm talking about one branch and backport only critical fixes.

I have no interest in backporting only critical fixes given that the Beaker users of versions < 3.9 are still the majority, so it would imply maintaining two branches. I still don't see the benefit of this and I will personally phase out Python versions when I see them going in disuse between our users.