[Python-Dev] Python 2.7 patch levels turning two digit
Donald Stufft
donald at stufft.io
Sun Jun 22 00:18:05 CEST 2014
On Jun 21, 2014, at 6:00 PM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> 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?
Stuff from PyPI installs later on in the sys.path than the stdlib. I wish it were different but it means without sys.path shenanigans you can’t replace the stdlib with something from PyPI.
>
> Top-posted from my Windows Phone
> From: M.-A. Lemburg
> Sent: 6/21/2014 14:38
> To: Chris Angelico
> Cc: Python-Dev
> 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.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/
> _______________________________________________
> 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
> _______________________________________________
> 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/donald%40stufft.io
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140621/84d43d27/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140621/84d43d27/attachment.sig>
More information about the Python-Dev
mailing list