Mailman 3 September 2017 - Python-Dev

Compiling without multithreading support -- still useful?
by Antoine Pitrou 07 Sep '17

07 Sep '17

Hello, It's 2017 and we are still allowing people to compile CPython without threads support. It adds some complication in several places (including delicate parts of our internal C code) without a clear benefit. Do people still need this? Regards Antoine.

6 11

PEP 550 discussion time out
by Guido van Rossum 07 Sep '17

07 Sep '17

I am declaring a time out for discussing of PEP 550 and its competitor, PEP 555. There has been some good discussion but also some mud-slinging (in various directions), and I've been frankly overwhelmed by the exchanges, despite having spent much of Tuesday talking to Yury about it and lying awake thinking about it for two nights since then. I need to sit down and think more about the problem we're trying to solve, what are the constraints (and why), and what would the minimal solution. -- --Guido van Rossum (python.org/~guido)

1 0

Cherry picker bot deployed in CPython repo
by Mariatta Wijaya 07 Sep '17

07 Sep '17

Hi, The cherry picker bot has just been deployed to CPython repo, codenamed miss-islington. 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 and 2.7) 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 you're ready. 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: https://pypi.org/project/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. Thanks! Mariatta Wijaya

4 4

New C API not leaking implementation details: an usable stable ABI
by Victor Stinner 07 Sep '17

07 Sep '17

Hi, 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: https://haypo.github.io/new-python-c-api.html 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! https://github.com/haypo/misc/blob/master/python/pep_c_api.rst 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 https://mail.python.org/pipermail/python-ideas/2017-July/046399.html This is not a request for comments :-) I will write a proper PEP for that. Victor

1 0

Python 3.3.7rc1 now available prior to Python 3.3 end-of-life
by Ned Deily 06 Sep '17

06 Sep '17

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: https://www.python.org/downloads/release/python-337rc1/ -- Ned Deily nad(a)python.org -- []

1 0

[RFC] Removing pure Python implementation of OrderedDict
by INADA Naoki 06 Sep '17

06 Sep '17

Hi, all. Currently, deque and defaultdict have only C implementation. Python implementations should provide _collections.deque and _collections.defaultdict. Like that, how about removing OrderedDict Pure Python implementation from stdlib and require it to implementation? ## Pros ### 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, like defaultdict. ### 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. See https://bugs.python.org/issue31265 While implementing it, I noticed that current test_ordered_dict has some tests about implementation detail without @cpython_only decorator. For example: https://github.com/python/cpython/blob/fcd97d44382df520e39de477a5ec99dd89c3… 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: https://bitbucket.org/pypy/pypy/src/ac3e33369ba0aa14278a6a3e8f2add09590d358… My pull request has same change: https://github.com/methane/cpython/pull/9/files#diff-23c28e7fa52967682669d9… 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 bit slower. ## Cons * All Python 3.7 implementations should provide _collections.OrderedDict PyPy has it already. But I don't know about micropython. Regards, INADA Naoki <songofacandy(a)gmail.com>

10 18

Looking for review on small argparse patch
by Anthony Sottile 06 Sep '17

06 Sep '17

As argparse seems to not have a current maintainer, I'm hoping a volunteer could review this small patch to the argparse module. I posted the PR nearly a month ago and have not received any feedback yet: https://github.com/python/cpython/pull/3027 bpo link: https://bugs.python.org/issue26510 Thanks in advance, Anthony

1 0

Workflow change reminder: The Blurb Has Landed
by Larry Hastings 05 Sep '17

05 Sep '17

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, etc. 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 quick refresher. 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 blurb". 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: https://devguide.python.org/committing/#what-s-new-and-news-entries and the documentation for blurb on PyPI: https://pypi.org/project/blurb/ 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. Happy blurbing! /arry * 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.

1 0

Version and Last-Modified headers are no longer required in PEPs.
by R. David Murray 05 Sep '17

05 Sep '17

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. --David

1 0

Map and Wirelessly Control the Human Brain Using 50 Nanometer Particles and Radio Waves
by Muresan Ionut Alexandru 05 Sep '17

05 Sep '17

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. Best regards, IonutIf you wish to unsubscribe from our newsletter, click http://r.sciencemedia.eu/336n1lt27ors7g.html

1 0