[Python-Dev] Python 2.7 patch levels turning two digit

[M.-A. Lemburg]

On 21.06.2014 22:34, Chris Angelico wrote:
> 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.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."
>>
>> 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.

There are no places in the stdlib that parse sys.version in a
way that would break wtih 2.7.10, AFAIK. I was just referring
to the statement that Nick quoted. sys.version *is* used for
parsing the Python version or using parts of it to build
e.g. filenames and that's really no surprise.

That said, and I also included this in my answers to the questions
that Nick removed in his reply, I don't think that a lot of
code would be affected by this. I do believe that we can use
this potential breakage as a chance for improvement. See the last
question (listed here again)...

1. Is it a good strategy to ship to Python releases for every
   single OpenSSL security release or is there a better way to
   handle these 3rd party issues ?

2. 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 ?

3. Should we make use of the potential breakage with 2.7.10
   to introduce a new Windows compiler version for Python 2.7 ?

My answers to these are: 1. We should use dynamic linking
instead and not let OpenSSL bugs trigger Python releases; 2.
It's not a big problem; 3. Yes, please, since it is difficult
for people to develop and debug their extensions with a
2008 compiler, when the rest of the world has long moved on.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 21 2014)
>>> Python Projects, Consulting and Support ...   http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2014-06-17: Released eGenix PyRun 2.0.0 ...       http://egenix.com/go58
2014-06-09: Released eGenix pyOpenSSL 0.13.3 ...  http://egenix.com/go57
2014-07-02: Python Meeting Duesseldorf ...                 11 days to go

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/