With PEP 466 and the constant flow of OpenSSL security fixes
which are currently being handled via Python patch level releases,
we will soon reach 2.7.10 and quickly go beyond that (also see
http://bugs.python.org/issue21308).
This opens up a potential backwards incompatibility with existing
On 21 June 2014 20:27, M.-A. Lemburg m...@egenix.com wrote:
With PEP 466 and the constant flow of OpenSSL security fixes
which are currently being handled via Python patch level releases,
we will soon reach 2.7.10 and quickly go beyond that (also see
http://bugs.python.org/issue21308).
This
On Jun 21, 2014, at 12:27 PM, M.-A. Lemburg wrote:
This opens up a potential backwards incompatibility with existing
tools that assume the Python release version number to use the
x.y.z single digit approach, e.g. code that uses sys.version[:5]
for the Python version or relies on the
On 21.06.2014 12:51, Nick Coghlan wrote:
On 21 June 2014 20:27, M.-A. Lemburg m...@egenix.com wrote:
With PEP 466 and the constant flow of OpenSSL security fixes
which are currently being handled via Python patch level releases,
we will soon reach 2.7.10 and quickly go beyond that (also see
In article 53a5b995.6040...@egenix.com,
M.-A. Lemburg m...@egenix.com wrote:
Making it harder to tell whether or not someone's Python installation
is affected by an OpenSSL CVE is also an undesirable outcome. On a
Linux distro, folks will check the distro package database directly
for the
On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg m...@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
On Sun, Jun 22, 2014 at 06:34:23AM +1000, Chris Angelico ros...@gmail.com
wrote:
Do you know where this problematic code is?
In many places:
https://encrypted.google.com/search?q=%22sys.version[%3A3]%22
https://encrypted.google.com/search?q=%22sys.version[%3A5]%22
Oleg.
--
Oleg
On 21.06.2014 22:34, Chris Angelico wrote:
On Sun, Jun 22, 2014 at 2:57 AM, M.-A. Lemburg m...@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
On 21/06/2014 10:37 pm, M.-A. Lemburg wrote:
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
On 06/21/2014 02:37 PM, M.-A. Lemburg wrote:
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
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
On Jun 21, 2014, at 6:00 PM, Steve Dower steve.do...@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...
On Sun, Jun 22, 2014 at 8:00 AM, Steve Dower steve.do...@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...
On Sun, Jun 22, 2014 at 7:37 AM, M.-A. Lemburg m...@egenix.com wrote:
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
14 matches
Mail list logo
