The cherry picker bot has just been deployed to CPython repo, codenamed
miss-islington made the very first backport PR for CPython and became a
first time GitHub contributor: https://github.com/python/cpython/pull/3369
GitHub repo: https://github.com/python/miss-islington
What is this?
As part of our workflow, quite often changes made on the master branch need
to be backported to the earlier versions. (for example: from master to 3.6
Previously the backport has to be done manually by either a core developer
or the original PR author.
With the bot, the backport PR is created automatically after the PR has
been merged. A core developer will need to review the backport PR.
The issue was tracked in https://github.com/python/core-workflow/issues/8
How it works
1. If a PR needs to be backported to one of the maintenance branches, a
core developer should apply the "needs backport to X.Y" label. Do this
**before** you merge the PR.
2. Merge the PR
3. miss-islington will leave a comment on the PR, saying it is working on
backporting the PR.
4. If there's no merge conflict, the PR should be created momentarily.
5. Review the backport PR created by miss-islington and merge it when
Merge Conflicts / Problems?
In case of merge conflicts, or if a backport PR was not created within 2
minutes, it likely failed and you should do the backport manually.
Manual backport can be done using cherry_picker:
Older merged PRs not yet backported?
At the moment, those need to be backported manually.
Don't want PR to be backported by a bot?
My recommendation is to apply the "needs backport to X.Y" **after** the PR
has been merged. The label is still useful to remind ourselves that this PR
still needs backporting.
Who is Miss Islington?
I found out from Wikipedia that Miss Islington is the name of the witch in
Monty Python and The Holy Grail.
miss-islington has not signed the CLA!
A core dev can ignore the warning and merge the PR anyway.
I am currently at a CPython sprint 2017 at Facebook. We are discussing
my idea of writing a new C API for CPython hiding implementation
details and replacing macros with function calls.
I wrote a short blog post to explain the issue of the current API, the
link between the API and the ABI, and give examples of optimizations
which become possible with an "unsable" stable ABI:
I am sorry, I'm too busy to write a proper PEP. But here is the link
to my old PEP draft written in June. I didn't update it yet. But
multiple people are asking me for the PEP draft, so here you have!
See also the thread on python-ideas last June, where I first proposed my draft:
[Python-ideas] PEP: Hide implementation details in the C API
This is not a request for comments :-) I will write a proper PEP for that.
On behalf of the Python development community and the Python 3.3 release teams, I would like to announce the availability of Python 3.3.7rc1, the release candidate of Python 3.3.7. It is a security-fix source-only release. Python 3.3.0 was released 5 years ago on 2012-09-29 and has been in security-fix-only mode since 2014-03-08. Per project policy, all support for the 3.3 series of releases ends on 2017-09-29, five years after the initial release. Therefore, Python 3.3.7 is expected to be the final release of any kind for the 3.3 series.
After 2017-09-29, **we will no longer accept bug reports nor provide fixes of any kind for Python 3.3.x**; of course, third-party distributors of Python 3.3.x may choose to offer their own extended support. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail. If you are still using Python 3.3.x, we **strongly** encourage you to upgrade to a more recent, fully supported version of Python 3; see https://www.python.org/downloads/. If you are still using your own build of Python 3.3.x , please report any critical issues with 3.3.7rc1 to the Python bug tracker prior to 2017-09-18, the expected release date for Python 3.3.7 final. Even better, use the time to upgrade to Python 3.6.x!
Thank you to everyone who has contributed to the success of Python 3.3.x over the past years!
You can find Python 3.3.7rc1 here:
nad(a)python.org -- 
Currently, deque and defaultdict have only C implementation.
Python implementations should provide _collections.deque
Like that, how about removing OrderedDict Pure Python implementation
from stdlib and require it to implementation?
### Thread safety
AFAIK, there are no thread safety guarantee in OrderedDict.
I don't look carefully, but some methods seems thread unsafe.
I'm considering adding `OrderedDict.lru_get(key, default=None)` which
atomically lookup key and move the key to end if found.
It can be used when functools.lru_cahce can't be used.
(see http://bugs.python.org/issue28193 )
And thread safety is very important for such method.
Anyway, thread safety will improve usability of OrderedDict significantly,
### Less maintenance cost of test_ordered_dict.
I'm sending pull request for removing doubly linked list from C OrderedDict,
for faster creatin, iteration, and reduce memory usage by 1/2.
While implementing it, I noticed that current test_ordered_dict has some
tests about implementation detail without @cpython_only decorator.
While current test expects KeyError, my pull request (and PyPy's OrderedDict)
doesn't raise KeyError because inconsistency between doubly linked list
and dict never happens.
PyPy changed the test:
My pull request has same change:
Maintain compatibility with odd behavior of Pure Python implementation
is not constructive job not only for us, but also other Python implementations.
### `import collections` bit faster.
Pure Python implementation has 5 classes (OrderedDict, _Link,
_OrderedDictKeyViews, _OrderedDictItemsView, and _OrderedDictValuesView).
Three of them inheriting from ABC. So it makes importing collections
* All Python 3.7 implementations should provide _collections.OrderedDict
PyPy has it already. But I don't know about micropython.
INADA Naoki <songofacandy(a)gmail.com>
Yesterday I "blurbified" the 2.7, 3.6, and master branches in CPython.
It's finally official: all* branches have now been "blurbified". This
means that Misc/NEWS is no longer present in any of CPython's active
branches. Instead, Misc/NEWS has been broken up into a zillion little
files in the new Misc/NEWS.d directory tree. (Misc/NEWS can be
reconstituted consistently from this directory tree.) This banishes
forever the annoying problem of Misc/NEWS merge conflicts when you
attempt to merge a pull request, when release managers create a release,
We announced "blurb" a month or two back, and you should already be
creating your news entries in Misc/NEWS.d. But just in case, here's a
The core-workflow team has created a tool called "blurb" that makes it
easy to create a news entry for a commit. It's easy to install and use.
You can install it with:
python3 -m pip install blurb
It requires Python 3.5 or newer. (Sorry, it can't get backported to 3.4
without fixing a bug in "re"... and 3.4 is closed for bugfixes.)
To create a news entry, just run blurb from anywhere inside your CPython
repo. On POSIX systems just make sure "blurb" is on your path, then
simply run "blurb". On Windows the recommended method is "python3 -m
When you run blurb, it'll guide you through creating a news entry. It'll
pop open an editor window on a template. Just modify the template as
needed, write your news entry at the bottom, and save and exit. blurb
will write out your news entry as a uniquely-named file in
Misc/NEWS.d--and even stage it for you in "git"!
If for some reason you want to create news entries by hand, or if you
just want more information, please see the Dev Guide:
and the documentation for blurb on PyPI:
The migration to Misc/NEWS.d and blurb has a few other implications:
1. Existing pending PRs or patches with Misc/NEWS entries will need to
be updated to generate the entry with blurb. (Again, there really
shouldn't /be/ any by this point.)
2. If you want to read a branch's NEWS entries in a convenient format,
simply use "blurb merge" to produce a temporary NEWS file. (But
don't check it in!) See the blurb documentation.
3. As part of the release process, release managers now use blurb to
merge all the individual NEWS.d/next files into a single NEWS.d file
for that version. They'll also build a traditional monolithic
Misc/NEWS included in the release's source tarball (but this won't
get checked in).
4. If you're building 3.x docs from a cpython git repo, you'll now need
to have blurb installed. You can use the "make venv" recipe in
Doc/Makefile to create a python3 venv with blurb and sphinx.
* All except 3.3. Ned Deily has taken over as release manager of 3.3,
and he thinks we shouldn't bother with blurbifying that branch--it'll
reach end-of-life in mere weeks, and we're only going to make one more
release of it, and it gets very little work done these days.
p.s. Thanks to Ned Deily who originally wrote this email, which I hacked
up and sent.
The Version and Last-Modified headers required by PEP1 used to be
maintained by the version control system, but this is not true now that
we've switched to git. We are therefore deprecating these headers and
have removed them from PEP1. The PEP generation script now considers
them to be optional.
If you are not able to see this mail, click http://r.sciencemedia.eu/336n1lt27ors7f.htmlHello,
I'm a computer programmer from Romania. I'm very interested in neuroscience. I have some ideas for an international science project.
The project is about increasing the worldwide efforts to map the human brain.
Methods that can be used to map and wirelessly control the brain
1. Study how the cordyceps mushroom controls the brains of ants. Create synthetic particles that can do the same in other life forms.
2. Use tiny transmitters (the size of a small bacteria) 50 nanometers each (decoder, antenna) that can send and receive data. The decoder should identify uniquely each neuron. They could be built using computer chip transistor technology (1 nanometers).
To get them close to each neuron they should be placed inside bacteria that can cross the blood-brain barrier. Another method to get them close to neurons is to inject them into the brain of the lab animal you experiment on.
3. Generate very low fequency radio waves that go through the human brain and in combination with the waves produced by the brain create a pattern that can be interpreted by a software.
In my opinion mapping the human brain will allow us to extend the lifespan of humans by at least 20 years all over the world, cure Parkinson, Alzheimer's, depression, senility (worth $1 trillion a year), cure cancer($2.5 trillion a year) and other ailments, and create human like artificial intelligence.
I think that mapping the human brain is the most important thing we can do in the next 10 years as a species. When it is finished this project will help us save trillions of dollars and millions of lives each year.
IonutIf you wish to unsubscribe from our newsletter, click http://r.sciencemedia.eu/336n1lt27ors7g.html
This module implements cplx class (complex numbers) regardless to the
The main goal of this module is to propose some improvement to complex
numbers in python and deal with them from a mathematical approach.
Also cplx class doesn't support the built-in class intentionally, as the
idea was to give an alternative to it.
With the hope I managed to succeed, here is the module :