On Sun, Jun 22, 2014 at 7:37 AM, M.-A. Lemburg 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 parts of it to
On Sun, Jun 22, 2014 at 8:00 AM, Steve Dower 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 id
On Jun 21, 2014, at 6:00 PM, Steve Dower 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 i
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 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 compiler,
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 las
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
>>> doc
On Sun, Jun 22, 2014 at 06:34:23AM +1000, Chris Angelico
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 Broytman
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 disclai
In article <53a5b995.6040...@egenix.com>,
"M.-A. Lemburg" 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 Ope
On 21.06.2014 12:51, Nick Coghlan wrote:
> On 21 June 2014 20:27, M.-A. Lemburg 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://b
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 lexicog
On 21 June 2014 20:27, M.-A. Lemburg 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 opens up a
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
tools
14 matches
Mail list logo
