[Python-Dev] Python 2.7 patch levels turning two digit (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sat Jun 21 12:51:54 CEST 2014
- Previous message: [Python-Dev] Python 2.7 patch levels turning two digit
- Next message: [Python-Dev] Python 2.7 patch levels turning two digit
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 21 June 2014 20:27, M.-A. Lemburg <mal at 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 | ncoghlan at gmail.com | Brisbane, Australia
- Previous message: [Python-Dev] Python 2.7 patch levels turning two digit
- Next message: [Python-Dev] Python 2.7 patch levels turning two digit
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]