Closed einarf closed 4 years ago
Sadly it was still 2.x. I would only drop the support if there was a technical reason to do it?
I guess this package is small enough that py2+py3 support is not a big hassle. I don't see any technical reasons for only doing py3 currently. My only worry is that it's getting increasingly difficult over time to set up dev enviroment (across different platform) if we go down to python 2.6 (Mentioned in #1). Using some version of 2.7 is a lot more maintainable.
I'm fine with any solution here as long as there is an official supported version constraint. 2.6+? 2.7+? + python 3.
2.7+ is fine for me. That centos5 machine was finally upgraded to debian8 in the meantime so I think I can abandon the idea of fixing it.
Great. Then the classifiers in setup.py is correct. Closing!
Is it still desirable to target both python 2 and python 3 for newer versions of this package? Python 2 is EOL in a few weeks, but users of this package might still be using python 2? I don't know.
I would suggest targeting python 3.5 and higher to make things simple. If it turns out python 2 support is important I will have to keep that in mind in future pull requests.
Adding python version information to
README.md
is also a very good idea.