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

Steve Dower Steve.Dower at microsoft.com
Sun Jun 22 00:00:14 CEST 2014

We can always lie about the version in sys.version. Existing code is unaffected and new code will have to use version_info (Windows developers will know that Windows pulls tricks like this every other version... doesn't make it a great idea, but it works).

Changing compiler without changing at least the install directory and preventing in place upgrades is a really bad idea, and with those mitigations is only pretty bad. I'm torn here, because I know the current situation hurts, but it'd probably only move to VC10 which will hurt just as much in a few years... there are better tooling solutions (yes, I'm working on some behind the scenes).

A separate distro of _ssl and _hashlib wouldn't be too hard and has the same effect as a dynamically linked OpenSSL. Maybe we can make these PyPI updateable?

Top-posted from my Windows Phone

From: M.-A. Lemburg<mailto:mal at egenix.com> Sent: ‎6/‎21/‎2014 14:38 To: Chris Angelico<mailto:rosuav at gmail.com> Cc: Python-Dev<mailto:python-dev at python.org> Subject: Re: [Python-Dev] Python 2.7 patch levels turning two digit

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.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.versioninfo. 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/

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140621/a1c2ee10/attachment-0001.html>

More information about the Python-Dev mailing list