On 24 Jun 2014 07:29, "Donald Stufft" wrote:
>
>
> On Jun 23, 2014, at 5:22 PM, Barry Warsaw 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 normal
On Jun 23, 2014, at 5:48 PM, Chris Angelico wrote:
> On Tue, Jun 24, 2014 at 6:42 AM, "Martin v. Löwis" 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, bu
On Tue, Jun 24, 2014 at 6:42 AM, "Martin v. Löwis" 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
> ABIs on Windows
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 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 and
On Jun 23, 2014, at 5:22 PM, Barry Warsaw 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 impact on th
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.
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 5:07 PM, M.-A. Lemburg wrote:
> On 23.06.2014 22:20, Donald Stufft wrote:
>>
>> On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote:
>>
>>> On 23.06.2014 18:09, Donald Stufft wrote:
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis wrote:
>>
>> * Should
In article <14de41e2-5314-4e49-be93-85eeeddde...@stufft.io>,
Donald Stufft wrote:
> On Jun 23, 2014, at 4:31 PM, Martin v. Lowis wrote:
>
> >>
> >> Would that mitigate the pain, assuming that
> >> Steve (or someone else) would be willing to build the additional
> >> installers for the trans
On 23.06.2014 22:20, Donald Stufft wrote:
>
> On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote:
>
>> On 23.06.2014 18:09, Donald Stufft wrote:
>>>
>>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis wrote:
>>>
>
> * Should we make use of the potential breakage with 2.7.10
> to introdu
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
somebo
On Jun 23, 2014, at 4:31 PM, Martin v. Löwis 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 installer
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 rea
> 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 co
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 main
On Jun 23, 2014, at 4:31 PM, Barry Warsaw 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 happen, for
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 tha
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
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 soluti
On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote:
> On 23.06.2014 18:09, Donald Stufft wrote:
>>
>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis wrote:
>>
* Should we make use of the potential breakage with 2.7.10
to introduce a new Windows compiler version for Python 2.7 ?
>
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
In article <53a87fb3.2000...@egenix.com>,
"M.-A. Lemburg" 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:
>
> What's
On 23.06.2014 18:09, Donald Stufft wrote:
>
> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis 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
On Jun 23, 2014, at 2:09 AM, Martin v. Löwis 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 a bad idea
> * 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
stil
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
y 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 wro
__
From: M.-A. Lemburg<mailto:m...@egenix.com>
Sent: 6/21/2014 14:38
To: Chris Angelico<mailto:ros...@gmail.com>
Cc: Python-Dev<mailto:python-dev@python.org>
Subject: Re: [Python-Dev] Python 2.7 patch levels turning two digit
On 21.06.2014 22:34, Chris Angelico wro
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
40 matches
Mail list logo
