On 06/10/2014 03:05 PM, "Martin v. Löwis" wrote:
We certainly don't need to resolve this now. We should discuss it again
when the release schedule for 3.5 is proposed.
I anticipate 3.5 should be released about 18 months after the release of
3.4, putting it mid-September 2015.
//arry/
__
Am 07.06.14 17:38, schrieb Steve Dower:
> One more possible concern that I just thought of is the availability of
> the build tools on Windows Vista and Windows 7 RTM (that is, without
> SP1). I'd have to check, but I don't believe anything after VS 2012 is
> supported on Vista and it's entirely po
Am 07.06.14 01:01, schrieb Steve Dower:
> We keep the VS 2010 files around and make sure they keep working.
> This is the biggest risk of the whole plan, but I believe that
> there's enough of a gap between when VS 14 is planned to release
> (which I know, but can't share) and when Python 3.5 is pl
One more possible concern that I just thought of is the availability of the
build tools on Windows Vista and Windows 7 RTM (that is, without SP1). I'd have
to check, but I don't believe anything after VS 2012 is supported on Vista and
it's entirely possible that installation is blocked.
This
Once 7 Jun 2014 06:19, "Nick Coghlan" wrote:
>
> On 7 June 2014 15:05, Donald Stufft wrote:
> > I don’t particularly care too much though, I just think that bumping
> > the compiler in a 2.7.Z release is a really bad idea and that either
> > of the other two options are massively better.
>
> It i
On Sat, Jun 7, 2014 at 7:05 AM, Donald Stufft wrote:
>
> I don’t particularly care too much though, I just think that bumping
> the compiler in a 2.7.Z release is a really bad idea and that either
> of the other two options are massively better.
+1
--
Giampaolo - http://grodola.blogspot.com
On 07/06/2014 02:13, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy wrote:
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote:
Brett Cannon wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we hav
On 7 June 2014 01:41, Steve Dower wrote:
>
> What this means for Python is that C extensions for Python 3.5 and later can
> be built using any version of MSVC from 14.0 and later. Those who are aware
> of the current state of affairs where you need to use a matching compiler
> will hopefully se
On 7 June 2014 15:05, Donald Stufft wrote:
> I don’t particularly care too much though, I just think that bumping
> the compiler in a 2.7.Z release is a really bad idea and that either
> of the other two options are massively better.
It is *incredibly* unlikely that backwards compatibility with b
On Jun 7, 2014, at 12:58 AM, Nick Coghlan wrote:
> On 7 June 2014 14:47, Donald Stufft wrote:
>> On Jun 7, 2014, at 12:41 AM, Nick Coghlan wrote:
>>>
>>> Words like "just", or "simple", or "easy" really have no place being
>>> applied to a task where the time required to fully execute it with
On 7 June 2014 14:47, Donald Stufft wrote:
> On Jun 7, 2014, at 12:41 AM, Nick Coghlan wrote:
>>
>> Words like "just", or "simple", or "easy" really have no place being
>> applied to a task where the time required to fully execute it with *no
>> significant problems* is still measured in years.
>
On 7 June 2014 14:01, Chris Barker wrote:
>>
>> Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
>> I cannot see why that would be massive undertaking, if changing compiler
>> for 2.7 is neccesary anyway.
>
>
> A reminder that this was brought up a few months ago, as a pr
On Jun 7, 2014, at 12:41 AM, Nick Coghlan wrote:
> On 7 June 2014 08:43, Sturla Molden wrote:
>> Brett Cannon wrote:
>>
>>> Nope. A new minor release of Python is a massive undertaking which is why
>>> we have saved ourselves the hassle of doing a Python 2.8 or not giving a
>>> clear signal a
On 7 June 2014 08:43, Sturla Molden wrote:
> Brett Cannon wrote:
>
>> Nope. A new minor release of Python is a massive undertaking which is why
>> we have saved ourselves the hassle of doing a Python 2.8 or not giving a
>> clear signal as to when Python 2.x will end as a language.
>
> Why not jus
>
>
> Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
> I cannot see why that would be massive undertaking, if changing compiler
> for 2.7 is neccesary anyway.
>
A reminder that this was brought up a few months ago, as a proposal by the
stackless team, as they wanted to
On 6/6/2014 9:13 PM, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy wrote:
If you are suggesting that a Windows compiler change should be
invisible to non-Windows users, I agree.
Let us assume that /pcbuild remains for those who have vc2008 and
that /pcbuild14 is added (and ev
Brian Curtin wrote:
>> If Python 2.7 users are left with a dead compiler on Windows, they will
>> find a solution. For example, Enthought is already bundling their Python
>> distribution with gcc 2.8.1 on Windows.
>
> Again, not something I think we should depend on. A lot of people use
> python
On Jun 6, 2014, at 9:05 PM, Terry Reedy wrote:
> On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
>> On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden
>> wrote:
>>> Brett Cannon wrote:
>>>
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the
On Jun 6, 2014 6:33 PM, "Sturla Molden" wrote:
>
> Brian Curtin wrote:
>
> > Well we're certainly not going to assume such a thing. I know people do
> > that, but many don't (I never have).
>
> If Python 2.7 users are left with a dead compiler on Windows, they will
> find a solution. For example,
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote:
Brett Cannon wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or not giving a
clear signal as to when Pyt
Eli Bendersky wrote:
> While we're at it, Clang in nearing a stage where it can compile C and C++
> on Windows *with ABI-compatibility to MSVC* (yes, even C++) -- see
> href="http://clang.llvm.org/docs/MSVCCompatibility.html";>http://clang.llvm.org/docs/MSVCCompatibility.html
> for more details.
On Fri, Jun 6, 2014 at 4:32 PM, Sturla Molden
wrote:
> Brian Curtin wrote:
>
> > Well we're certainly not going to assume such a thing. I know people do
> > that, but many don't (I never have).
>
> If Python 2.7 users are left with a dead compiler on Windows, they will
> find a solution. For exa
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote:
> Brett Cannon wrote:
>
>> Nope. A new minor release of Python is a massive undertaking which is why
>> we have saved ourselves the hassle of doing a Python 2.8 or not giving a
>> clear signal as to when Python 2.x will end as a language.
>
>
Brian Curtin wrote:
> Well we're certainly not going to assume such a thing. I know people do
> that, but many don't (I never have).
If Python 2.7 users are left with a dead compiler on Windows, they will
find a solution. For example, Enthought is already bundling their Python
distribution with
On Jun 6, 2014 6:01 PM, "Sturla Molden" wrote:
>
> Brian Curtin wrote:
>
> > Adding features into 3.x is already not enough of a carrot on the
> > stick for many users. Intentionally leaving 2.7 on a dead compiler is
> > like beating them with the stick.
>
> Those who want to build extensions on
Martin v. Löwis wrote:
> Am 06.06.14 22:13, schrieb Paul Moore:
>> From
>> http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs
>>
>> """
>> Currently, Visual Studio "14" CTPs have known compatibility issues
>> with previous releases of Visual Studio and should not be installed
>> si
Brian Curtin wrote:
> Adding features into 3.x is already not enough of a carrot on the
> stick for many users. Intentionally leaving 2.7 on a dead compiler is
> like beating them with the stick.
Those who want to build extensions on Windows will just use MinGW
(currently GCC 2.8.2) instead.
N
Brett Cannon wrote:
> Nope. A new minor release of Python is a massive undertaking which is why
> we have saved ourselves the hassle of doing a Python 2.8 or not giving a
> clear signal as to when Python 2.x will end as a language.
Why not just define Python 2.8 as Python 2.7 except with a newer
On Fri, Jun 6, 2014 at 11:42 PM, wrote:
> On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:
>
>> > Is it really any difference in maintenance if you just stop applying
>> > updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
>> > new compiler then there should be no f
Hi.
On 6.6.2014. 21:46, Guido van Rossum wrote:
A reminder:
https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg
*ROFL*
Subtle, ain't he? *gdr*
Best regards,
Jurko Gospodnetić
_
Am 06.06.14 22:13, schrieb Paul Moore:
> From http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs
>
> """
> Currently, Visual Studio "14" CTPs have known compatibility issues
> with previous releases of Visual Studio and should not be installed
> side-by-side on the same computer.
On Sat, Jun 7, 2014 at 5:42 AM, wrote:
> Perhaps a final alternative is simply continuing
> the 2.7 series with a stale compiler, as a kind of carrot on a stick to
> encourage users to upgrade?
More likely, what would happen is that there'd be an alternate
distribution of Python 2.7 (eg ActiveSt
On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:
> > Is it really any difference in maintenance if you just stop applying
> > updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
> > new compiler then there should be no functional difference between
> > doing that and
Am 06.06.14 21:20, schrieb "Martin v. Löwis":
> 2. what is the risk of installing a beta compiler on what might
>otherwise be a "production" developer system? In particular, could
>it interfere with other VS installations, and could it require a
>complete system reinstall when the final
On 6 June 2014 20:20, "Martin v. Löwis" wrote:
> 2. what is the risk of installing a beta compiler on what might
>otherwise be a "production" developer system? In particular, could
>it interfere with other VS installations, and could it require a
>complete system reinstall when the fin
A reminder:
https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
On Sat, Jun 7, 2014 at 5:36 AM, Donald Stufft wrote:
> Well it’d contain bug fixes and whatever other sorts of things you’d put
> into a 2.7.whatever release. So they’d still want to upgrade to 2.8 since
> that’ll have bug fixes.
But it's not a potentially-breaking change. For example, on Debian
Am 06.06.14 20:25, schrieb Brian Curtin:
> We're going to have to change it at some point, otherwise we're going
> to have people in 2018 scrambling to find VS2008, which will be 35
> versions too old by then.
Not sure whether you picked 2018 deliberately: extended support for
VS2008 Professional
On Jun 6, 2014, at 3:33 PM, Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft wrote:
>> Is it really any difference in maintenance if you just stop applying updates
>> to
>> 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then
>> there
>> should be no
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft wrote:
> Is it really any difference in maintenance if you just stop applying updates
> to
> 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then
> there
> should be no functional difference between doing that and doing a 2.7.wha
Am 06.06.14 19:31, schrieb Brian Curtin:
>> If that's a non-issue, or if we can actually drop XP support, I'm all for it.
>
> Extended support ended in April of this year, so I think we should put
> XP as unsupported for 3.5 in PEP 11 -
> http://legacy.python.org/dev/peps/pep-0011/
>
> I seem to
Am 06.06.14 17:41, schrieb Steve Dower:
> Hi all
>
> I would like to propose moving Python 3.5 to use Visual C++ 14.0 as
> the main compiler.
This is fine with me, but I'm worried about the precise timing of doing
so. I assume that you would plan to do this moving before VC++ 14 is
actually relea
On Jun 6, 2014, at 3:09 PM, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote:
>>
>> On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
>>
>>> On Fri, Jun 6, 2014 at 10:56 PM, wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
> None o
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote:
>
> On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
>
>> On Fri, Jun 6, 2014 at 10:56 PM, wrote:
>>> On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
>>>
None of the options are particularly good, but yes, I think that's an
On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:56 PM, wrote:
>> On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
>>
>>> None of the options are particularly good, but yes, I think that's an
>>> option we have to consider. We're supporting 2.7.x for 6
On Fri Jun 06 2014 at 2:59:24 PM, wrote:
> On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
>
> > None of the options are particularly good, but yes, I think that's an
> > option we have to consider. We're supporting 2.7.x for 6 more years on
> > a compiler that is already 6 years ol
On Fri, Jun 6, 2014 at 10:56 PM, wrote:
> On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
>
>> None of the options are particularly good, but yes, I think that's an
>> option we have to consider. We're supporting 2.7.x for 6 more years on
>> a compiler that is already 6 years old.
>
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
> None of the options are particularly good, but yes, I think that's an
> option we have to consider. We're supporting 2.7.x for 6 more years on
> a compiler that is already 6 years old.
Surely that is infinitely less desirable than si
On 06.06.2014 20:49, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg wrote:
>> On 06.06.2014 20:25, Brian Curtin wrote:
>>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
wrote:
> Chris Angelico wrote:
>>
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg wrote:
> On 06.06.2014 20:25, Brian Curtin wrote:
>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
>>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
>>> wrote:
Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>>
On 06.06.2014 20:25, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
>> wrote:
>>> Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
wrote:
> What this means for Python is that C extension
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote:
>> Chris Angelico wrote:
>>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>>> wrote:
What this means for Python is that C extensions for Python 3.5 and later
can be built using
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote:
> Chris Angelico wrote:
>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>> wrote:
>>> What this means for Python is that C extensions for Python 3.5 and later
>>> can be built using any version of MSVC from 14.0 and later.
>>
>> Oh, if only this
Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower wrote:
>> What this means for Python is that C extensions for Python 3.5 and later can
>> be built using any version of MSVC from 14.0 and later.
>
> Oh, if only this had been available for 2.7!! Actually... this means that
> 14
Stefan Krah wrote:
>Stefan Krah wrote:
>> > * Will VS 14 be golden prior to Python 3.5's release? It would suck to
>> > rely on a beta compiler.. :)
>>
>> This is my only concern, too. Otherwise, +1 for the switch.
>
>One more thing: Will the SDK 64-bit tools be available for the Express
>Vers
dw+python-...@hmmz.org wrote:
> Speaking as a third party who aims to provide binary distributions for recent
> Python releases on Windows, every new compiler introduces a licensing and
> configuration headache. So I guess the questions are:
>
> * Does the ABI stability address some historical rea
On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware
wrote:
> On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower
> wrote:
>> Thoughts/comments/concerns?
>
> My only concern is support for elderly versions of Windows, in
> particular: XP. I seem to recall the last "let's update our MSVC
> version" discussion
Stefan Krah wrote:
> > * Will VS 14 be golden prior to Python 3.5's release? It would suck to
> > rely on a beta compiler.. :)
>
> This is my only concern, too. Otherwise, +1 for the switch.
One more thing: Will the SDK 64-bit tools be available for the Express
Versions?
Stefan Krah
_
On Fri, 06 Jun 2014 16:37:01 -, dw+python-...@hmmz.org wrote:
> On Fri, Jun 06, 2014 at 03:41:22PM +, Steve Dower wrote:
>
> > [snip]
>
> Speaking as a third party who aims to provide binary distributions for
> recent Python releases on Windows, every new compiler introduces a
> licensing
dw+python-...@hmmz.org wrote:
> * Has Python ever hit a showstopper release issue as a result of a bug
> in MSVC? (I guess probably not).
Yes, a PGO issue:
http://bugs.python.org/issue15993
To be fair, in that issue I did not look if there's some undefined behavior in
longobject.c.
> * Wil
On Fri, Jun 06, 2014 at 03:41:22PM +, Steve Dower wrote:
> [snip]
Speaking as a third party who aims to provide binary distributions for
recent Python releases on Windows, every new compiler introduces a
licensing and configuration headache. So I guess the questions are:
* Does the ABI stabi
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower wrote:
> Thoughts/comments/concerns?
My only concern is support for elderly versions of Windows, in
particular: XP. I seem to recall the last "let's update our MSVC
version" discussion dying off because of XP support. Even though MS
has abandoned it,
On 6 June 2014 16:41, Steve Dower wrote:
> Basically, what I am offering to do is:
>
> * Update the files in PCBuild to work with Visual Studio "14"
> * Make any code changes necessary to build with VC14
> * Regularly test the latest Python source with the latest MSVC builds and
> report issues/s
On Jun 6, 2014, at 11:41 AM, Steve Dower wrote:
> words
+1 from me.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
__
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower wrote:
> What this means for Python is that C extensions for Python 3.5 and later can
> be built using any version of MSVC from 14.0 and later.
Oh, if only this had been available for 2.7!! Actually... this means
that 14.0 would be a good target for a
Hi all
I would like to propose moving Python 3.5 to use Visual C++ 14.0 as the main
compiler. The first CTP of Visual Studio "14" was released earlier this week:
http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx
The major feature of interest in this version of MSVC is
66 matches
Mail list logo
