On Sep 22, 2014, at 8:20 PM, Larry Hastings wrote:

On 09/19/2014 03:31 PM, Barry Warsaw wrote:

...

I think we need a Python 3.5 Release Schedule PEP.

Just checked it in as PEP 478. It should show up here in a few minutes: http://legacy.python.org/dev/peps/pep-0478/ http://legacy.python.org/dev/peps/pep-0478/

Key facts: Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015 sprints. Final release is September 13, 2015, just over a year from now.

Comments?

It says 3.4.0 all through it. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 09/24/2014 08:04 AM, Victor Stinner wrote:

It was too distrubing to read "3.4" in the "3.5" schedule. I modified the PEP directly, sorry Larry.

No sweat. I would have fixed it myself, but yesterday was a big travel day. Thanks for fixing it! //arry/

On 23 September 2014 19:46, Nick Coghlan wrote:

Under consideration (in addition to the items already listed in the PEP):

PEP 432 (simplifying the startup sequence) PEP 475 (retry system calls failing with EINTR) Improved Windows console Unicode support (see https://pypi.python.org/pypi/win_unicode_console for details) Changing the encoding and error handling of an existing stream (http://bugs.python.org/issue15216)

A few more specific Unicode related proposals that may be worth mentioning in the release PEP (aside from the binary data formatting mini-language one, they're generally not PEP worthy in their own right, but they do relate directly to addressing some of the remaining concerns with binary data handling in Python 3, which is a fairly high profile topic): Allowing "backslashreplace" to be used on input: http://bugs.python.org/issue22286 Adding "codecs.convert_surrogateescape": http://bugs.python.org/issue18814 Adding "wsgiref.util.dump_wsgistr" and "wsgiref.util.load_wsgistr": http://bugs.python.org/issue22264 Adding "bytes.hex", "bytearray.hex" and "memoryview.hex": http://bugs.python.org/issue9951 Adding a binary data formatting mini-language (depends on 9951): http://bugs.python.org/issue22385 There's also your own PEP 457 to formalise the syntax used to communicate signature information from Argument Clinic to the inspect module as a string - I don't know if you were planning to revisit that for 3.5 and potentially make creating inspect.Signature objects from such strings a public API. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 24 September 2014 03:05, Steve Dower wrote:

Larry Hastings wrote:

...

On 09/19/2014 03:31 PM, Barry Warsaw wrote: I think we need a Python 3.5 Release Schedule PEP.

Just checked it in as PEP 478. It should show up here in a few minutes: http://legacy.python.org/dev/peps/pep-0478/

Key facts: . Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015 sprints. . Final release is September 13, 2015, just over a year from now.

Comments?

Martin is no longer producing the Windows installers - that task has been handed to me. I'm planning to have a rewritten installer (also in the same repo) that should be easier to modify and maintain, as well as being able to produce alternative packages (such as a Python 3.5 or stdlib merge module, for example), though that doesn't necessarily need to go into the PEP.

I'm also considering/experimenting with installing into "Program Files" by default, but I suspect that isn't going to work out yet.

I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like the best available compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically means "we think this is ready for use, but expect a round of minor updates/fixes soon - the compiler is least likely to be updated, my guess is that it'll be Visual Studio UI mostly).

I personally don't have any qualms about using the RC compiler for Beta 1, and Beta 2 will almost certainly use VC 14 RTM, but I know when I proposed this topic that some people were concerned about having the final version available for Python 3.5 Beta.

So far I've been building regularly with internal versions of VC and haven't been hitting any major issues with Python (OpenSSL has some issues, but I've been filing bugs on both sides so they should be worked out soon enough). My work is at http://hg.python.org/sandbox/steve.dower (branch: VC14) for anyone interested.

For the alphas, I'm contemplating producing two builds (VC 10 and VC 14), but I obviously want to settle on one or the other by Beta. Last time we discussed it, there was strong support for changing compiler, but I have a better idea of the timeline now and it's tighter than I thought...

Thoughts, anyone?

It's ultimately up to Larry as RM, but I'd personally favour targeting the newer compiler and runtime, even with the slight risk of potentially needing to slip our schedule. There's also a fair amount of wiggle room between the first beta and the first release candidate. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

"This new compiler has the incredibly awesome feature of being forwards compatible right? Like in 10 years stuff compiled with a newer compiler will still work?" That's the promise at least :) All the macros that leaked implementation details (like file descriptors) are now isolated so if they change it won't break existing applications. It'll still be possible for newer compiler versions to break them, but the design now obviously discourages it. There's also an official guarantee, so if it is broken in future it'll be treated as a bug. As much as I'd love to make solid promises, I can only pass on the promises that were made to me. But yes, we should have forward compatibility with later MSVC versions, which will help avoid the situation where it's hard to get hold of the right compiler... Top-posted from my Windows Phone ________________________________ From: Donald Stufftmailto:donald@stufft.io Sent: ‎9/‎23/‎2014 18:50 To: Nick Coghlanmailto:ncoghlan@gmail.com Cc: Steve Dowermailto:Steve.Dower@microsoft.com; python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] 3.5 release schedule PEP On Sep 23, 2014, at 9:48 PM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote: On 24 September 2014 03:05, Steve Dower mailto:Steve.Dower@microsoft.com> wrote: Larry Hastings wrote: On 09/19/2014 03:31 PM, Barry Warsaw wrote: I think we need a Python 3.5 Release Schedule PEP. Just checked it in as PEP 478. It should show up here in a few minutes: http://legacy.python.org/dev/peps/pep-0478/ Key facts: . Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015 sprints. . Final release is September 13, 2015, just over a year from now. Comments? Martin is no longer producing the Windows installers - that task has been handed to me. I'm planning to have a rewritten installer (also in the same repo) that should be easier to modify and maintain, as well as being able to produce alternative packages (such as a Python 3.5 or stdlib merge module, for example), though that doesn't necessarily need to go into the PEP. I'm also considering/experimenting with installing into "Program Files" by default, but I suspect that isn't going to work out yet. I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like the best available compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically means "we think this is ready for use, but expect a round of minor updates/fixes soon - the compiler is least likely to be updated, my guess is that it'll be Visual Studio UI mostly). I personally don't have any qualms about using the RC compiler for Beta 1, and Beta 2 will almost certainly use VC 14 RTM, but I know when I proposed this topic that some people were concerned about having the final version available for Python 3.5 Beta. So far I've been building regularly with internal versions of VC and haven't been hitting any major issues with Python (OpenSSL has some issues, but I've been filing bugs on both sides so they should be worked out soon enough). My work is at http://hg.python.org/sandbox/steve.dower (branch: VC14) for anyone interested. For the alphas, I'm contemplating producing two builds (VC 10 and VC 14), but I obviously want to settle on one or the other by Beta. Last time we discussed it, there was strong support for changing compiler, but I have a better idea of the timeline now and it's tighter than I thought... Thoughts, anyone? It's ultimately up to Larry as RM, but I'd personally favour targeting the newer compiler and runtime, even with the slight risk of potentially needing to slip our schedule. There's also a fair amount of wiggle room between the first beta and the first release candidate. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.commailto:ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.orgmailto:Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io This new compiler has the incredibly awesome feature of being forwards compatible right? Like in 10 years stuff compiled with a newer compiler will still work? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On 24.09.2014 03:48, Nick Coghlan wrote:

On 24 September 2014 03:05, Steve Dower wrote:

...

Larry Hastings wrote:

...

On 09/19/2014 03:31 PM, Barry Warsaw wrote: I think we need a Python 3.5 Release Schedule PEP.

Just checked it in as PEP 478. It should show up here in a few minutes: http://legacy.python.org/dev/peps/pep-0478/

Key facts: . Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015 sprints. . Final release is September 13, 2015, just over a year from now.

Comments?

Martin is no longer producing the Windows installers - that task has been handed to me. I'm planning to have a rewritten installer (also in the same repo) that should be easier to modify and maintain, as well as being able to produce alternative packages (such as a Python 3.5 or stdlib merge module, for example), though that doesn't necessarily need to go into the PEP.

I'm also considering/experimenting with installing into "Program Files" by default, but I suspect that isn't going to work out yet.

I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like the best available compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically means "we think this is ready for use, but expect a round of minor updates/fixes soon - the compiler is least likely to be updated, my guess is that it'll be Visual Studio UI mostly).

I personally don't have any qualms about using the RC compiler for Beta 1, and Beta 2 will almost certainly use VC 14 RTM, but I know when I proposed this topic that some people were concerned about having the final version available for Python 3.5 Beta.

So far I've been building regularly with internal versions of VC and haven't been hitting any major issues with Python (OpenSSL has some issues, but I've been filing bugs on both sides so they should be worked out soon enough). My work is at http://hg.python.org/sandbox/steve.dower (branch: VC14) for anyone interested.

For the alphas, I'm contemplating producing two builds (VC 10 and VC 14), but I obviously want to settle on one or the other by Beta. Last time we discussed it, there was strong support for changing compiler, but I have a better idea of the timeline now and it's tighter than I thought...

Thoughts, anyone?

It's ultimately up to Larry as RM, but I'd personally favour targeting the newer compiler and runtime, even with the slight risk of potentially needing to slip our schedule. There's also a fair amount of wiggle room between the first beta and the first release candidate.

I'd rather be conservative here and wait for another Python release before switching VC versions. There are a few important questions that need answers before we can consider a new VC version: * Will there be free versions available ? * Will those free editions include the 64-bit compilers ? * Will those free editions include the optimizing compilers ? * Is there a roadmap for how long these free versions will remain officially available ? * Are there issues compiling 3rd party libraries with it ? E.g. the numeric and science stacks, the web stacks, the deployment stacks, etc. * What license terms will the new version have ? E.g. GPL compatibility issues, weird exceptions, * What will the pricing structure look like ? While core devs will get free MSDN licenses, most other 3rd party providers will have to buy licenses for the compiler, unless they can use the free versions. An alternative would be targeting VC13 instead of VC14, in case it has good answers for the above questions. It's been around for a year now, so there should be more experience available with this version. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 24 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-09-27: PyDDF Sprint 2014 ... 3 days to go 2014-09-30: Python Meeting Duesseldorf ... 6 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

Thanks for the insights, Steve. More below... On 24.09.2014 18:52, Steve Dower wrote:

M.-A. Lemburg wrote:

...

I'd rather be conservative here and wait for another Python release before switching VC versions. There are a few important questions that need answers before we can consider a new VC version:

* Will there be free versions available ?

* Will those free editions include the 64-bit compilers ?

* Will those free editions include the optimizing compilers ?

* Is there a roadmap for how long these free versions will remain officially available ?

* Are there issues compiling 3rd party libraries with it ?

E.g. the numeric and science stacks, the web stacks, the deployment stacks, etc.

* What license terms will the new version have ?

E.g. GPL compatibility issues, weird exceptions,

* What will the pricing structure look like ?

While core devs will get free MSDN licenses, most other 3rd party providers will have to buy licenses for the compiler, unless they can use the free versions.

An alternative would be targeting VC13 instead of VC14, in case it has good answers for the above questions. It's been around for a year now, so there should be more experience available with this version.

(Nit - it's actually VC12 a.k.a. "Visual Studio 2013" - VC13 was skipped. This is what happens when you have separate engineering and marketing teams :) )

Ah, ok :-)

I don't have good answers to all of these yet, but none of them are going to be any worse than for VC12. I've forwarded these questions to the people on the VC team who do get to choose the answers, and while I'm not expecting to hear specifics back from them, they are at least aware of the concerns and how important their product is to our community.

There will be free versions available, but I don't know what format they'll be in. Those free editions should include identical compilers to the paid ones - the cases where that hasn't been true have been bugs or due to assumptions that were proven to be incorrect.

The main improvement in this version is that all versions from VC14 should be binary compatible, and so there will always be a free compiler, but it may be VC15/16/etc. and not VC14.

That's good news.

There are certainly issues with 3rd party libraries, largely because all projects have a tendency to take dependencies on compiler/library internals. OpenSSL, for example, redefines the stdout/in/err macros based on the VC version, but the new definitions are no longer valid with VC14, and so they are fixing that. Python itself has a few issues that I have already fixed in my branch. There will certainly be other issues, but an advantage of starting early is that bugs in the compiler itself can be fixed in the compiler.

The license should not change significantly from previous versions. GPL incompatibilities are because the GPL wants to be incompatible with licenses based on different ideologies - AFAIK there's never been anything in the VC licenses preventing whatever redistribution license you like.

As example: there once was a special clause which explicitly disallowed "Excluded License[s]" to be used together with VC redistibutable files. I think this is no longer the case, but there may be new things in the EULAs.

Part of my improvements to /PCBuild will help avoid the need for Visual Studio entirely, but the free versions should always be sufficient for building and debugging. I have no insight or control over the pricing structure.

Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 24 2014)

...

...

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-09-27: PyDDF Sprint 2014 ... 3 days to go 2014-09-30: Python Meeting Duesseldorf ... 6 days to go ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On 09/24/2014 09:11 PM, Larry Hastings wrote:

Therefore: if VC14 doesn't ship by 3.5 RC1, currently set at August 5, 2015, I decree we have to ship 3.5 with the previous version.

Reasonable?

Seems reasonable to me. -- ~Ethan~

On 24 Sep 2014 15:15, "Tim Golden" wrote:

On 23/09/2014 18:05, Steve Dower wrote:

...

I'm also considering/experimenting with installing into "Program Files" by default, but I suspect that isn't going to work out yet.

I'd like to see that go forward: I think it's increasingly difficult to

justify Python's position at c:\pythonxx. But it does run the risk of

breaking All The Things. When it was discussed, people spoke about symlinks (or hardlinks / junctions / whatever) in the appropriate places to support hardcoded paths, but I don't know how feasible that will turn out to be.

It might be better to offer that as a supported option in 3.5, and then make it the default in 3.6. That will offer a couple of years to work out the issues, rather than a few months.

...

I'd like to move the Windows versions onto the next release of VC (currently "VC 14" until the branding team figures out what to call it). There isn't a promised RTM date for VC 14 yet, so it looks like the best available compiler by Beta 1 will be a "Go Live" RC. (The "Go Live" marking basically means "we think this is ready for use, but expect a round of minor updates/fixes soon - the compiler is least likely to be updated, my guess is that it'll be Visual Studio UI mostly).

My only real misgiving here is that, for a few years, we'll need *three* versions installed to build the active branches: 2008 for 2.7; 2010 for 3.4; and 2014 for 3.5. Am I wrong?

3.4 will go into security fix only mode a few months after 3.5 is released, as happened with 3.3. It does suggest that we shouldn't switch the compiler until: 1. At least a beta of VC 2014 is generally available 2. We're a few weeks out from 3.5 beta 1 (with VC 2014 as an option until then) Cheers, Nick.

TJG

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com

Am 24.09.14 14:34, schrieb Antoine Pitrou:

On Wed, 24 Sep 2014 17:12:35 +1000 Nick Coghlan wrote:

...

On 24 Sep 2014 15:15, "Tim Golden" wrote:

...

On 23/09/2014 18:05, Steve Dower wrote:

...

I'm also considering/experimenting with installing into "Program Files" by default, but I suspect that isn't going to work out yet.

...

It might be better to offer that as a supported option in 3.5, and then make it the default in 3.6.

I would be surprised if this weren't already a supported option. Decent Windows installers generally allow you to override the installation path (it's been a while I haven't used the Windows Python installer, sorry).

I regularly test whether it installs properly into Program Files (although regularly actually means "for every major release"). Also, users regularly report if it doesn't work. As it turns out, 3.4 indeed got a new problem when installing into Program Files, namely that pip would not install. As discussed elsewhere in this thread, installation into Program Files requires elevated privileges, which meant that I had to reschedule the pip installation procedure within the MSI to run in the system context.

I think making the move in 3.5 would be a good idea. Experts can override the installation path and choose C:\PythonXY. There's no actual breakage since the path changes for every major release, anyway (i.e. people would have had to change the path from "C:\Python34" to "C:\Python35"; instead, they will have to change it to "C:\Program Files\Python35").

I expect breakage elsewhere (as also discussed): - some code will fail because of the space in the path - some installations will fail because of the restricted access to Program Files (which, of course, is also the main reason why people want that install location) It's of course now up to Steve to rule on the default install location; if he changes it, he will get lots of both praise and blame, if he doesn't change it, he will get a little blame for continuing the tradition. Regards, Martin