On Jun 21, 2014, at 12:27 PM, M.-A. Lemburg wrote: >This opens up a potential backwards incompatibility with existing >tools that assume the Python release version number to use the >"x.y.z" single digit approach, e.g. code that uses sys.version[:5] >for the Python version or relies on the lexicographic ordering >of the version string (sys.version > '2.7.2'). Patient: Doctor, it hurts when I do this. Doctor: Don't do that! > * Should we try to avoid two digit patch level release numbers > by using some other mechanism such as e.g. a release date > after 2.7.9 ? > > Grepping through our code, this will introduce some breakage, > but not much. Most older code branches on minor versions, > not patch levels. More recent code uses sys.python_info so > is not affected. s/sys.python_info/sys.version_info/ and yes the latter has been preferred for a long time now. Given that 2.7 is a long term support release, it's inevitable that we'll break the 2-digit micro release number barrier. So be it. A 2.7.10 isn't the end of the world. -Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4