I proposed a patch to drop the CALL_PROFILE special build to simplify
I modified ceval.c for fast calls in Python 3.6, and I'm not sure that
the feature still works correctly. The feature is not well documented
and not tested at all.
For fast calls, I moved some code, so it's more complex to update call
statistics since statistics are implemented in ceval.c.
I would like to completely remove the feature to be able to implement
I'd love to be able to get http://bugs.python.org/issue28288 into 2.7.12 .
I've found the -3 flag to be immensely useful when porting Python code to
Python 3, but unfortunately it can be difficult to use with services that
run python in subprocesses (like Gunicorn or Xdist with py.test). With
this patch I'd be able to set the `PYTHON3WARNINGS` environment variable to
ensure I get warnings everywhere.
Thanks, let me know what you think,
I am trying to build a custom Conda installer for Python 3.6.0b4.
I could successfully build an run Python. However, when I run
the generated Conda installer, it dies with a "Bus error".
It happens when Conda's meta-installer script tries to replace
the build-prefix (e.g., /home/stefan/conda/asdf) with the prefix
of the actual installation (e.g., /tmp/py36).
Therefore, it opens all files in binary mode, reads their contents,
replaces stuff, and writes the new contents back to the original file.
This works fine with text files but it dies when it hits the first
Here is a minimal example that reproduces the error:
Python 3.6.0b4 (default, Nov 22 2016, 10:32:29)
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux
>>> path = '/tmp/py36/lib/libpython3.6m.so.1.0'
>>> f = open(path, 'wb')
Can anyone reproduce this? Is this a compilation error or an issue
with Python itself?
PS: If need, I can upload the Conda installer somewhere. It's ~40MiB.
On behalf of the Python development community and the Python 3.6 release
team, I'm pleased to announce the availability of Python 3.6.0b4. 3.6.0b4
is the last planned beta release of Python 3.6, the next major release of
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.0b4 here:
Beta releases are intended to give the wider community the opportunity
to test new features and bug fixes and to prepare their projects to
support the new feature release. We strongly encourage maintainers of
third-party Python projects to test with 3.6 during the beta phase and
report issues found to bugs.python.org as soon as possible. While the
release is feature complete entering the beta phase, it is possible that
features may be modified or, in rare cases, deleted up until the start
of the release candidate phase (2016-12-05). Our goal is have no changes
after rc1. To achieve that, it will be extremely important to get as
much exposure for 3.6 as possible during the beta phase. Please keep in
mind that this is a preview release and its use is not recommended for
The next pre-release of Python 3.6 will be 3.6.0rc1, the release candidate,
currently scheduled for 2016-12-05. The official release of Python 3.6.0
is currently scheduled for 2016-12-16. More information about the release
schedule can be found here:
nad(a)python.org -- 
For anyone who's interested, I ran a quick analysis of the download
stats from python.org for CPython 3.6.0 releases since September.
As Mac and Linux users typically get their downloads from elsewhere,
those stats are on the low side. However, we've been getting roughly 10k
downloads/day for Windows, and even though it's been out less than 24
hours, 3.6.0b4 is already
There's a PDF with charts at:
My spreadsheet is at
(Excel format), if you want to see actual numbers. But there is likely
some lost data in here and almost certainly some hits counted that
shouldn't be (e.g. the spike on the 19th of September is *probably* a
broken browser update causing multiple hits for each download - I
haven't gone through UA data to figure it out yet, but Chrome has
definitely done this in the past).
Treat the actual numbers with a grain of salt, but overall it looks like
we've had pretty good usage of the prerelease versions of 3.6.
The final beta snapshot planned for the 3.6 release cycle is scheduled to be tagged today within the next 12 hours. We then begin the Release Candidate stage, the final days leading up to 3.6.0, with the release candidate scheduled to be tagged in about 2 weeks. As I have noted previously, with the tagging today and release of beta 4, *all* non-critical bug fixes for 3.6.0 should now have been checked in. From the b4 tag on, *only* release critical and doc fixes should be pushed for the release candidate. A reminder from the Developer's Guide regarding the Release Candidate stage of the release cycle:
"A branch preparing for an RC release can only have bugfixes applied that have been reviewed by other core developers. Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point. You cannot skip the peer review during an RC, no matter how small! Even if it is a simple copy-and-paste change, everything requires peer review from a core developer."
A goal for this release has been to have no changes between the release candidate and the final release other than the tag itself. Remember that every time we make a change at this point, it puts a burden on and adds risk to our testing efforts and, more importantly, the efforts of our third-party package developers, downstream distributors, and end users helping us ensure that 3.6.0 will be a high-quality release. I think everyone has been doing a great job so far in exercising good judgement about what is appropriate at each stage of our release cycle. Thank you! Now, after b4, unless a code change addresses a truly release critical issue, please target bug fixes for 3.6.1 and, of course, continue to target new features for 3.7.
This raises the issue of what process to follow for changes to the 3.6 branch following the b4 tag and up to the final 3.6.0 release. During the last feature release cycle (3.5.0), we tried something a little bit different: having a 3.5 branch open during the beta phase and then using a special Bitbucket repo with pull requests for changes in the release candidate phase. This was intended to ease the burden on us release managers trying to cherry pick a set of fixes into the RC and/or final releases while allowing the 3.5 branch to remain open to everyone for 3.5.1 changes. My sense is that, while we all appreciated keeping the branch open for bug fixes, many of us were new to the Bitbucket PR process and found it more confusing than expected. So for 3.6.0, I am trying to avoid going down that route. But I do need your help. First, throughout the release cycle I have tried to set expectations that the release candidate will be exactly what it says, a candidate for final release, and thus there should be at most a *very* small number of release critical fixes and final doc updates going in after b4 and with the goal of no changes after rc1. Second, by keeping the rc phase changes to a minimum, I have also tried to keep the release candidate phase shorter so that we all can move on to focus on the next feature release and on maintenance releases for 3.6 (schedules for both will be proposed soon). Also, 3.6.0 is the last feature release cycle using our current development workflow. Sometime after the 3.6.0 release, we will be phasing in our revised development workflow (thanks to Brett and crew!) and with it will come the opportunity for greater flexibility throughout the release cycle, with new tools like pull requests workflows and continuous integration testing. So I don't think it makes sense to spend a lot of time tweaking our current process just for the final weeks of one release.
Therefore, what I am planning to do and asking you to do is:
1. Sometime after 1800 UTC today when we are ready to start the 3.6.0b4 tagging and release manufacturing process, I will send an email announcement.
2. Following that b4 tag notification and until rc1 is tagged on 2016-12-05 (in about two weeks), the 3.6 branch will *temporarily* be open only for fixes appropriate for 3.6.0, e.g. reviewed release critical items and final doc changes. Don't forget to mark such items as "release blocker" in the bug tracker.
3. Hold off pushing changes that are not 3.6.0 release critical until after rc1 is tagged. You can continue to push bug fixes as appropriate to other open branches if you are willing to back port them to the 3.6 branch, as necessary, after rc1 is tagged. Or, if you prefer to follow the normal development flow, take a bugfix holiday for the next two weeks and just hold off pushing any changes that affect 3.6.1 until after rc1 is tagged. With those (hopefully) small inconveniences to you, we won't have to go through a special Bitbucket PR process and it will ensure that our 3.6 buildbots continue to test what's going into 3.6.0.
4. Once rc1 is tagged, the 3.6 branch will again be open for the usual maintenance-release-appropriate changes destined for 3.6.1. Any emergency fixes that might arise after rc1 and prior to 3.6.0 will be approved and merged from the 3.6 branch into the 3.6.0 release by me. I'm really hoping we won't have to do that!
I hope that you find the process for the few remaining weeks leading up to the 3.6.0 release to not be too burdensome. Please contact me if you have any questions about the 3.6.0 schedule or about whether a change is appropriate at this point in the 3.6.0 cycle.
To recap, the remaining milestones for 3.6.0:
2016-11-21, ~1800 UTC: 3.6.0 beta 4 (important bug fixes and doc fixes)
2016-11-21 to 2016-12-05: 3.6 branch open *only* for 3.6.0 release critical and doc fixes
2016-12-05 (2 weeks from now) 3.6.0 release candidate 1 (3.6.0 code freeze, release critical bug fixes, doc fixes; 3.6 branch reopens for 3.6.1)
2016-12-16 3.6.0 release (3.6.0rc1 plus any necessary emergency fixes)
Thank you all again for your efforts so far on 3.6. Beethoven and I are looking forward to celebrating 3.6.0 on 12-16!
nad(a)python.org -- 
I'm trying to fix refleaks in 3.6. So far:
On 2016-11-09 4:02 AM, solipsis(a)pitrou.net wrote:
> results for b78574cb00ab on branch "default"
> test_ast leaked [98, 98, 98] references, sum=294
> test_ast leaked [98, 98, 98] memory blocks, sum=294
> test_asyncio leaked [3, 0, 0] memory blocks, sum=3
> test_code leaked [2, 2, 2] references, sum=6
> test_code leaked [2, 2, 2] memory blocks, sum=6
> test_functools leaked [0, 3, 1] memory blocks, sum=4
> test_pydoc leaked [106, 106, 106] references, sum=318
> test_pydoc leaked [42, 42, 42] memory blocks, sum=126
> test_trace leaked [12, 12, 12] references, sum=36
> test_trace leaked [11, 11, 11] memory blocks, sum=33
test_ast, test_code and test_trace were fixed by
test_pydoc leaks in test_typing_pydoc. I tried git bisect and it looks
like that the first commit that introduced the refleak was the one that
62127e60e7b0 doesn't modify any CPython internals, so it looks like that
test_typing_pydoc exposed some bug that has existed before it. Any help
tracking that down is welcome :)