(original) (raw)
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
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
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 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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com
\> On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg 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@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com