On 21 June 2014 20:27, M.-A. Lemburg <m...@egenix.com> wrote: > With PEP 466 and the constant flow of OpenSSL security fixes > which are currently being handled via Python patch level releases, > we will soon reach 2.7.10 and quickly go beyond that (also see > http://bugs.python.org/issue21308). > > 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').
Such code has an easy fix available, though, as sys.version_info has existed since 2.0, and handles two digit micro releases just fine. The docs for sys.version also have this explicit disclaimer: "Do not extract version information out of it, rather, use version_info and the functions provided by the platform module." Making it harder to tell whether or not someone's Python installation is affected by an OpenSSL CVE is also an undesirable outcome. On a Linux distro, folks will check the distro package database directly for the OpenSSL version, but on Windows, no such centralised audit mechanism is available by default. With OpenSSL statically linked, Python versions can just be mapped to OpenSSL versions (so, for example, 2.7.7 has 1.0.1g) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
