Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Nick Coghlan 
On 23 September 2014 10:20, 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/

Thanks. Some updates on specific things either already accepted, or
under consideration for inclusion:

Already implemented:

   PEP 465 (matrix multiplication operator):
http://www.python.org/dev/peps/pep-0465/
   Standard streams default to the "surrogateescape" error handler if
ASCII is reported as the IO encoding (improves tolerance of the POSIX
C locale)

Already accepted:

PEP 461 (binary printf-style formatting):
http://www.python.org/dev/peps/pep-0461/
PEP 471 (os.scandir): http://www.python.org/dev/peps/pep-0471/

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)

(432 was previously listed as deferred, but it went back on my todo
list once 3.4 was out the door)

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 3.4.2rc1 Mac OS X

2014-09-23 Thread Carol Willing 

To all who contributed to Mac OS X improvements:

Thank you!

I downloaded and installed last night on Mavericks 10.9. It was quick, 
straightforward, and completed in seconds. For contrast, I talked 
several new users at an Intro to Python workshop this past weekend how 
to install 3.4.1; it took about 5 minutes to guide each user through 
installing 3.4.1. The new 3.4.2rc1 installer is a *big* improvement.


It also seems as if launching the interpreter from the command line is 
also faster now :)


--
*Carol Willing*
Developer | Willing Consulting
+1 760 456 9366 | https://willingconsulting.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Steve Dower 
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?

Cheers,
Steve

> /arry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4.2rc1 Mac OS X

2014-09-23 Thread Ned Deily 
In article <[email protected]>,
 Carol Willing  wrote:
> [...] The new 3.4.2rc1 installer is a *big* improvement.

Thanks for the feedback, Carol.  Let us know via bugs.python.org of any 
issues you see.  BTW, the new installer format will be coming to Python 
2.7.9 as well.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Nick Coghlan 
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   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Donald Stufft 

> On Sep 23, 2014, at 9:48 PM, 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.
> 
> Regards,
> Nick.
> 
> -- 
> Nick Coghlan   |   [email protected]    |   
> Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected] 
> 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

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Donald Stufft 

> On Sep 23, 2014, at 10:14 PM, Steve Dower  wrote:
> 
> "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

Yea I think it makes incredible sense to aim for it then, even if it makes 
things slip.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Steve Dower 
"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 Stufft
Sent: ‎9/‎23/‎2014 18:50
To: Nick Coghlan
Cc: Steve Dower; 
[email protected]
Subject: Re: [Python-Dev] 3.5 release schedule PEP


On Sep 23, 2014, at 9:48 PM, Nick Coghlan 
mailto:[email protected]>> wrote:

On 24 September 2014 03:05, Steve Dower 
mailto:[email protected]>> 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   |   [email protected]   |   
Brisbane, Australia
___
Python-Dev mailing list
[email protected]
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

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

2014-09-23 Thread Tim Golden 

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.



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?


TJG
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com