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
39 matches
Mail list logo
