Since the question has already come up and there will likely be further changes, let's keep it simple: feel free to make changes in the 3.6 branch to Doc/whatsnew/3.6.rst for 3.6.0 and I will cherrypick those changes just prior to producing the 3.6.0 final. Likewise with Misc/NEWS. As stated before, any other potential changes require a 3.6 checkin and a "release blocker" issue in the tracker.
nad(a)python.org -- 
OK, rc1 is now out the door. Thanks to everyone who helped resolve the remaining release blocker issues.
As of now, the code base for 3.6.0 final is frozen. The 3.6 branch is now open for code that will be released in 3.6.1, the first 3.6 maintenance release. As usual, that means bug fixes, security fixes, and documentation updates. Refer to the Developer's Guide for more information on the development cycle. If you have any questions about whether a change is appropriate for a 3.6.x maintenance release, please ask.
During the period between rc1 and the final release (scheduled for 2016-12-16), please continue to test 3.6.0rc1 and encourage others to do so. Repeating what I wrote earlier:
Should any emergency showstopper problems be discovered affecting 3.6.0rc1, please open an issue, mark it as "release blocker", if possible push a fix to the 3.6 branch for 3.6.1, and we will discuss what action to take for 3.6.0. As I've mentioned many times now, my goal is to have *no* code changes for 3.6.0 after rc1 so you will have to make a *really* strong case to add any code changes after rc1 and prior to the final release scheduled for 12-16. Should the need arise for such a change, it would be cherrypicked from the 3.6 branch. I am more willing to consider cherry-picking pure doc changes after rc1 but these will also need to be pushed to 3.6 and marked as "release blocker".
Counting down the days to the final release!
nad(a)python.org -- 
On behalf of the Python development community and the Python 3.6 release
team, I'm excited to announce the availability of Python 3.6.0rc1. 3.6.0rc1
is the release candiate for Python 3.6, the next major release of
Code for 3.6.0 is now frozen. Assuming no release critical problems are
found prior to the 3.6.0 final release date, currently 2016-12-16, the
3.6.0 final release will be the same code base as this 3.6.0rc1.
Maintenance releases for the 3.6 series will follow at regular
intervals starting in the first quarter of 2017.
Among the new major new features in Python 3.6 are:
* PEP 468 - Preserving the order of **kwargs in a function
* PEP 487 - Simpler customization of class creation
* PEP 495 - Local Time Disambiguation
* PEP 498 - Literal String Formatting
* PEP 506 - Adding A Secrets Module To The Standard Library
* PEP 509 - Add a private version to dict
* PEP 515 - Underscores in Numeric Literals
* PEP 519 - Adding a file system path protocol
* PEP 520 - Preserving Class Attribute Definition Order
* PEP 523 - Adding a frame evaluation API to CPython
* PEP 524 - Make os.urandom() blocking on Linux (during system startup)
* PEP 525 - Asynchronous Generators (provisional)
* PEP 526 - Syntax for Variable Annotations (provisional)
* PEP 528 - Change Windows console encoding to UTF-8
* PEP 529 - Change Windows filesystem encoding to UTF-8
* PEP 530 - Asynchronous Comprehensions
Please see "What’s New In Python 3.6" for more information:
You can find Python 3.6.0rc1 here:
Note that 3.6.0rc1 is still a preview release and thus its use is not
recommended for production environments.
More information about the release schedule can be found here:
nad(a)python.org -- 
Today I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 17 licenses available - of the licenses I asked for last year, three people took them up, so those are in use and come out of the allocation of 20. In the unlikely event that there is much greater take up this year and we use up all 20, we can ask for more.
If any of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account.
The final hours for fixes for 3.6.0 are here. Although the cutoff for 3.6.0rc1 is scheduled for today, we are still reviewing a few last release-critical fixes, primarily my fault for not pinging these earlier. So I'm going to hold off tagging rc1 for another 12 hours or so. This is your last chance to get release-critical fixes in for 3.6.0. After rc1 is tagged and released, the 3.6 branch will be open again for normal maintenance-release changes which will first be released in 3.6.1 in the first quarter of 2017.
Should any emergency showstopper problems be discovered affecting 3.6.0rc1, please open an issue, mark it as "release blocker", if possible push a fix to the 3.6 branch, and we will discuss what action to take for 3.6.0. As I've mentioned many times now, my goal is to have *no* code changes for 3.6.0 after rc1 so you will have to make a *really* strong case to add any code changes after rc1 and prior to the final release scheduled for 12-16. Should the need arise for such a change, it would be cherrypicked from the 3.6 branch. I am more willing to consider cherry-picking pure doc changes after rc1 but these will also need to be pushed to 3.6 and marked as "release blocker".
Thank you all once again for all of your hard work in getting 3.6 to this point! It's going to be a really good release!
nad(a)python.org -- 
The PEP 487 implementation included some changes to the way the
implicit __class__ cell is initialised in order to allow zero-argument
super() to work properly in class methods called from __set_name__ and
Unfortunately, the specific implementation chosen turned out to have
an obscure incompatibility with certain custom metaclasses, notably
including the metaclass for Model objects in Django. While there's a
patch pending to fix the incompatibility in Django, this should really
be a deprecation warning on the CPython side, rather than an abrupt
The latest patches attached to issue 23722 partially revert the
previous changes, and update the data model documentation to cover the
new constraints on custom metaclass implementations that want to
support zero-argument super():
Aside from the unintentional backwards compatibility break, the main
reason this is a release blocker is that in order to detect the
problematic case, we need to revert some of the changes previously
made to the bytecode generated for class statements (some opcodes had
been dropped as no longer needed, but now we need them again for error
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I'm not sure who I should send this to, so here it is:
$ curl -i https://mail.python.org/mailman/listinfo/python-buildbots
HTTP/1.1 200 OK
Date: Thu, 01 Dec 2016 11:47:20 GMT
Server: Apache/2.4.7 (Ubuntu)
<head><title>Bug in Mailman version 2.1.23</title></head>
<body bgcolor=#ffffff><h2>Bug in Mailman version 2.1.23</h2>
<p><h3>We're sorry, we hit a bug!</h3>
<p>Please inform the webmaster for this site of this
problem. Printing of traceback and other system information has been
explicitly inhibited, but the webmaster can find this information in the
Mailman error logs.