I am attempting to do the right thing and am following the advice of other core devs in what I have done thus far.
Borrowing heavily from what I've added to issue35813 just now: This work is the result of ~1.5 years of development effort, much of it accomplished at the last two core dev sprints. The code behind it has been stable since September 2018 and tested as an independently installable package by multiple people. I was encouraged by Lukasz, Yury, and others to check in this code early, not waiting for tests and docs, in order to both solicit more feedback and provide for broader testing. I understand that doing such a thing is not at all a novelty. Thankfully it is doing that -- I hope that feedback remains constructive and supportive. There are some tests to be found in a branch (enh-tests-shmem) of github.com/applio/cpython which I think should become more comprehensive before inclusion. Temporarily deferring and not including them as part of the first alpha should reduce the complexity of that release. Regarding the BSD license on the C code being adopted, my conversations with Brett and subsequently Van have not raised concerns, far from it -- there is a process which is being followed to the letter. If there are other reasons to object to the thoughtful adoption of code licensed like this one, that deserves a decoupled and larger discussion first. Davin On Sun, Feb 3, 2019 at 8:12 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > > On Feb 3, 2019, at 5:40 PM, Terry Reedy <tjre...@udel.edu> wrote: > > > > On 2/3/2019 7:55 PM, Guido van Rossum wrote: > >> Also, did anyone ask Davin directly to roll it back? > > > > Antoine posted on the issue, along with Robert O. Robert reviewed and > make several suggestions. > > I think the PR sat in a stable state for many months, and it looks like > RO's review comments came *after* the commit. > > FWIW, with dataclasses we decided to get the PR committed early, long > before most of the tests and all of the docs. The principle was that bigger > changes needed to go in as early as possible in the release cycle so that > we could thoroughly exercise it (something that almost never happens while > something is in the PR stage). It would be great if the same came happen > here. IIRC, shared memory has long been the holy grail for > multiprocessing, helping to mitigate its principle disadvantage (the cost > of moving data between processes). It's something we really want. > > But let's see what the 3.8 release manager has to say. > > > Raymond > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/python%2Bpython_dev%40discontinuity.net >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
