Movatterモバイル変換
[0]ホーム
[Python-Dev] Python 2.7 patch levels turning two digit
Steve DowerSteve.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:38To: 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 digitOn 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 away that would break wtih 2.7.10, AFAIK. I was just referringto the statement that Nick quoted. sys.version *is* used forparsing the Python version or using parts of it to builde.g. filenames and that's really no surprise.That said, and I also included this in my answers to the questionsthat Nick removed in his reply, I don't think that a lot ofcode would be affected by this. I do believe that we can usethis potential breakage as a chance for improvement. See the lastquestion (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 linkinginstead and not let OpenSSL bugs trigger Python releases; 2.It's not a big problem; 3. Yes, please, since it is difficultfor people to develop and debug their extensions with a2008 compiler, when the rest of the world has long moved on.--Marc-Andre LemburgeGenix.comProfessional 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/go582014-06-09: Released eGenix pyOpenSSL 0.13.3 ...http://egenix.com/go572014-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 46611http://www.egenix.com/company/contact/_______________________________________________Python-Dev mailing listPython-Dev at python.orghttps://mail.python.org/mailman/listinfo/python-devUnsubscribe: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-Devmailing list
[8]ページ先頭