Anthony prepared some statistics a while back showing the proportion of users on each version of Python. Maybe an updated chart will help convince the community here?
Samuel Marks http://linkedin.com/in/samuelmarks On Thu, Nov 21, 2019 at 10:17 PM anthony shaw <anthony.p.s...@gmail.com> wrote: > Considering libcloud has had the Metadata 1.2 tag for the minimum required > Python version, if we dropped 2.7 and 3.3, 3.4, then users would simply > install an old version. > https://packaging.python.org/guides/dropping-older-python-versions/ > > We put those attributes over a year ago. > > I'd be hugely in favor, there would be a lot of other simplicity and > refactoring that could be done around the storage driver, the file > handling, buffering, string interpolation, etc. > > We have stable versions of Libcloud that support 2.7, users would still use > those. We should decide if we want to maintain a 'critical fix only' > branch. > > Another consideration in the future would be the async support for the API, > which attempts to do have stalled because we have to support Python 2 and > 3.4. > > Anthony Shaw > > ------------------------------ > *From:* Tomaz Muraus <to...@apache.org> > *Sent:* Wednesday, November 20, 2019 7:18 pm > *To:* dev@libcloud.apache.org > *Subject:* [dev] Dropping support for old Python versions (2.7 and 3.4) > > Everyone, > > Python 2.7 is reaching EOL in just a couple of months. I think makes sense > for us to drop support for all the Python versions which are not actively > supported and maintained anymore. > > This means Python 2.7, Python 3.4 and PyPy 2. > > A lot of the larger and popular Python projects have already done that > (py.test, paramiko, eventlet, etc.). > > I propose dropping support for those two versions in a next major release > which should coincide with Python 2.7 EOL date. > > Dropping support for Python 2.7 will also allow us to eventually get rid of > our libcloud.utils.py3 wrapper and remove a lot of Python 2 and Python 3 > compatibility code (which will also result in cleaner and easier to read > code). > > Do keep in mind though that the plan is to approach this in an incremental > manner. > > First step will just be stopping testing with those Python versions and > removing those versions from classifiers section in setup.py. > > Actually getting rid of "libcloud.utils.py3" and other Python 2 / 3 > compatibility code will be much more involved and likely take much more > time. > > What do others think? > > Regards, > Tomaz >
