* 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 ?
At least for Windows, a new release certainly needs to be made.
It could be possible to produce MSI patch files, but this would
still
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
* Should we make use of the potential breakage with 2.7.10
to introduce a new Windows compiler version for Python 2.7 ?
Assuming it is a good idea to continue producing Windows binaries
for 2.7, I think it would be
On 23.06.2014 18:09, Donald Stufft wrote:
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
* Should we make use of the potential breakage with 2.7.10
to introduce a new Windows compiler version for Python 2.7 ?
Assuming it is a good idea to continue producing
In article 53a87fb3.2000...@egenix.com,
M.-A. Lemburg m...@egenix.com wrote:
[...]
But without access to the VS 2008 compiler that is needed to
compile those extensions, it will become increasingly difficult
for package authors to provide such binary packages, so we have to
ask ourselves:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions
for Windows for more than a decade, and egg and msi distributions
for 8 years :-)
But without access to the VS 2008 compiler that is needed to
compile those extensions,
It does seem to
On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg m...@egenix.com wrote:
On 23.06.2014 18:09, Donald Stufft wrote:
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
* Should we make use of the potential breakage with 2.7.10
to introduce a new Windows compiler version for
On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:
At the risk of getting Guido to post his slide again, I still think the
solution to the old compiler is to just roll a 2.8 with minimal changes.
No. It's not going to happen, for all the reasons discussed previously.
Python 2.8 is not a
On 06/23/2014 01:04 PM, Antoine Pitrou wrote:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions
for Windows for more than a decade, and egg and msi distributions
for 8 years :-)
But without access to the VS 2008 compiler that is needed
Am 23.06.14 22:04, schrieb Antoine Pitrou:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions
for Windows for more than a decade, and egg and msi distributions
for 8 years :-)
But without access to the VS 2008 compiler that is needed
On Jun 23, 2014, at 4:31 PM, Barry Warsaw ba...@python.org wrote:
On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:
At the risk of getting Guido to post his slide again, I still think the
solution to the old compiler is to just roll a 2.8 with minimal changes.
No. It's not going to
Am 23.06.14 21:53, schrieb Ned Deily:
It does seem like a conundrum. As I have no deep Windows experience to
be able to have an appreciation of all of the technical issues involved,
I ask out of ignorance: would it be possible and desirable to provide a
transition period of n 2.7.x
Antoine Pitrou wrote:
Le 23/06/2014 15:27, M.-A. Lemburg a écrit :
Not sure what you mean. We've had binary wininst distributions for
Windows for more than a decade, and egg and msi distributions for 8
years :-)
But without access to the VS 2008 compiler that is needed to compile
those
Am 23.06.14 22:31, schrieb Barry Warsaw:
On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:
At the risk of getting Guido to post his slide again, I still think the
solution to the old compiler is to just roll a 2.8 with minimal changes.
No. It's not going to happen, for all the reasons
On Jun 23, 2014, at 4:31 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Would that mitigate the pain, assuming that
Steve (or someone else) would be willing to build the additional
installers for the transition period? I've done something similar on a
smaller scale with the OS X 32-bit
Am 23.06.14 22:31, schrieb Barry Warsaw:
Well, on reason is that you'd have to convince MvL or someone else to take
over the work that would require, but that's gotta be *much* lighter weight
than releasing a Python 2.8.
Just to point this out in a separate message: it will have to be
somebody
On 23.06.2014 22:20, Donald Stufft wrote:
On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg m...@egenix.com wrote:
On 23.06.2014 18:09, Donald Stufft wrote:
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
* Should we make use of the potential breakage with 2.7.10
to
In article 14de41e2-5314-4e49-be93-85eeeddde...@stufft.io,
Donald Stufft don...@stufft.io wrote:
On Jun 23, 2014, at 4:31 PM, Martin v. Lowis mar...@v.loewis.de wrote:
Would that mitigate the pain, assuming that
Steve (or someone else) would be willing to build the additional
On Jun 23, 2014, at 5:07 PM, M.-A. Lemburg m...@egenix.com wrote:
On 23.06.2014 22:20, Donald Stufft wrote:
On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg m...@egenix.com wrote:
On 23.06.2014 18:09, Donald Stufft wrote:
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Not being a Python developer, I normally just lurk on Py-Dev, but I figured
I'd throw this out there for this thread:
Recent version of Maya embed Python 2.x, and the newer version of Maya (I
believe 2012 was the first version) embeds a Python 2.7 compiled with VS
2010. From my experience, most C
On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:
Normally when I see someone suggest that switching compilers
in 2.7.x is likely to be less work than releasing a 2.8 It normally
appears to me they haven’t looked at the impact on the packaging
tooling.
Just to be clear, releasing a Python 2.8
On Jun 23, 2014, at 5:22 PM, Barry Warsaw ba...@python.org wrote:
On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:
Normally when I see someone suggest that switching compilers
in 2.7.x is likely to be less work than releasing a 2.8 It normally
appears to me they haven’t looked at the
On 06/21/2014 02:48 PM, Ethan Furman wrote:
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
On Jun 23, 2014, at 05:28 PM, Donald Stufft wrote:
Can you clarify?
What support guarantees will we make about Python 2.8? Will it be supported
as long as Python 2.7? Longer? Will we now have two long-term support
versions or change *years* of expectations that users should transition off of
On Tue, Jun 24, 2014 at 6:42 AM, Martin v. Löwis mar...@v.loewis.de wrote:
See my other message. It's actually heavier, since it requires changes
to distutils, PyPI, pip, buildout etc., all which know how to deal with
Python minor version numbers, but are unaware of the notion of competing
On Jun 23, 2014, at 5:48 PM, Chris Angelico ros...@gmail.com wrote:
On Tue, Jun 24, 2014 at 6:42 AM, Martin v. Löwis mar...@v.loewis.de wrote:
See my other message. It's actually heavier, since it requires changes
to distutils, PyPI, pip, buildout etc., all which know how to deal with
Python
On 24 Jun 2014 07:29, Donald Stufft don...@stufft.io wrote:
On Jun 23, 2014, at 5:22 PM, Barry Warsaw ba...@python.org wrote:
On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:
Normally when I see someone suggest that switching compilers
in 2.7.x is likely to be less work than
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
.-A. Lemburgmailto:m...@egenix.com
Sent: 6/21/2014 14:38
To: Chris Angelicomailto:ros...@gmail.com
Cc: Python-Devmailto:python-dev@python.org
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 m
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 m...@egenix.com wrote:
On 21.06.2014 12:51, Nick Coghlan wrote:
Such code has an easy fix available, though
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
40 matches
Mail list logo
