[Python-Dev] Python 2.7 patch levels turning two digit (original) (raw)

Chris Angelico rosuav at gmail.com
Sat Jun 21 22:34:23 CEST 2014

On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg <mal at egenix.com> wrote:

On 21.06.2014 12:51, Nick Coghlan wrote:

Such code has an easy fix available, though, as sys.versioninfo 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 versioninfo and the functions provided by the platform module." I don't think that's a good argument. Of course, there are better ways to figure out the version number, but fact is, existing code, even in the stdlib, does use and parse the sys.version string version. During Python's lifetime, we've always avoided two digit version numbers, so people have been relying on this, even if it was never (AFAIK) documented anywhere.

It's going to be a broken-code-breaking change that's introduced in a point release, but since PEP 404 implicitly says that there won't be a 2.10.0, there's no way around that. Although actually, a glance at the stdlib suggests that 2.10.0 (or 3.10.0) would break a lot more than 2.7.10 would break - there are places where sys.version[:3] is used (or equivalents like "... %.3s ..." % sys.version), or a whole-string comparison is done against a two-part version string (eg: sys.version

= "2.6"), and at least one place that checks sys.version[0] for the major version number, but I didn't find any that look at sys.version[:5] or equivalent. Everything that cares about the three-part version number seems to either look at sys.version.split()[0] or sys.version_info. Do you know where this problematic code is?

I checked this in the 2.7.3 stdlib as packaged on my Debian Wheezy system, for what it's worth.

ChrisA

More information about the Python-Dev mailing list