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 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
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
On 07/06/2014 02:13, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor
On Sat, Jun 7, 2014 at 7:05 AM, Donald Stufft don...@stufft.io 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 -
Once 7 Jun 2014 06:19, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 15:05, Donald Stufft don...@stufft.io 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
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
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 a
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com 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
On Jun 6, 2014, at 11:41 AM, Steve Dower steve.do...@microsoft.com 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 6 June 2014 16:41, Steve Dower steve.do...@microsoft.com 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
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower steve.do...@microsoft.com 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
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
dw+python-...@hmmz.org 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
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 and
Stefan Krah ste...@bytereef.org 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?
On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
Thoughts/comments/concerns?
My only concern is support for elderly versions of Windows, in
particular: XP. I seem to recall the
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 real
Stefan Krah wrote:
Stefan Krah ste...@bytereef.org 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
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com 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...
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
What this means for Python is that C extensions for Python 3.5 and later
can be built using any version of MSVC
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
What this means for Python is that C
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg m...@egenix.com wrote:
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
wrote:
Chris Angelico wrote:
On Sat,
On 06.06.2014 20:49, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg m...@egenix.com wrote:
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
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
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org 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
On Fri Jun 06 2014 at 2:59:24 PM, dw+python-...@hmmz.org 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
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org 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.
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft don...@stufft.io wrote:
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are
On Jun 6, 2014, at 3:09 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft don...@stufft.io wrote:
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at
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
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
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft don...@stufft.io 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
On Jun 6, 2014, at 3:33 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft don...@stufft.io 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
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 Sat, Jun 7, 2014 at 5:36 AM, Donald Stufft don...@stufft.io 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
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
On 6 June 2014 20:20, Martin v. Löwis mar...@v.loewis.de 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
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 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 doing a
On Sat, Jun 7, 2014 at 5:42 AM, dw+python-...@hmmz.org 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
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.
I also
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ć
On Fri, Jun 6, 2014 at 11:42 PM, dw+python-...@hmmz.org 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
Brett Cannon bcan...@gmail.com 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
Brian Curtin br...@python.org 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
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
side-by-side on the
On Jun 6, 2014 6:01 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brian Curtin br...@python.org 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
Brian Curtin br...@python.org 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
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com 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
On Fri, Jun 6, 2014 at 4:32 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Brian Curtin br...@python.org 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
Eli Bendersky eli...@gmail.com 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
a
href=http://clang.llvm.org/docs/MSVCCompatibility.html;http://clang.llvm.org/docs/MSVCCompatibility.html/a
for
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com 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
On Jun 6, 2014 6:33 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brian Curtin br...@python.org 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
On Jun 6, 2014, at 9:05 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking
Brian Curtin br...@python.org 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
On 6/6/2014 9:13 PM, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy tjre...@udel.edu 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
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 use a
On 7 June 2014 08:43, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com 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
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 08:43, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing
On 7 June 2014 14:01, Chris Barker chris.bar...@noaa.gov 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
On 7 June 2014 14:47, Donald Stufft don...@stufft.io wrote:
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com 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
On Jun 7, 2014, at 12:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 14:47, Donald Stufft don...@stufft.io wrote:
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
Words like just, or simple, or easy really have no place being
applied to a task where the
On 7 June 2014 15:05, Donald Stufft don...@stufft.io 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
On 7 June 2014 01:41, Steve Dower steve.do...@microsoft.com 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
66 matches
Mail list logo
