[Python-Dev] Asking for reversion

[Davin Potts]

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.hettinger at gmail.com> wrote:

>
> > On Feb 3, 2019, at 5:40 PM, Terry Reedy <tjreedy at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/python%2Bpython_dev%40discontinuity.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190203/82686044/attachment.html>