
On 1 July 2017 at 11:53, Nathaniel Smith <njs@pobox.com> wrote:
I just attempted an experimental refactor/streamlining of PEP 517, to match what I think it should look like :-). I haven't submitted it as a PR to the PEPs repository yet since I don't know if others will agree with the changes, but I've pasted the full text below, or you can see the text online at:
I'm a little confused - is this a formalisation of the proposals you've already made on this thread, or is it something different? So far the discussions we've had have been on points of dispute with the existing PEP 517, which have been relatively easy to follow. I don't really have the time to go through this proposal looking for the points of similarity and the differences with PEP 517. I feel like we're pretty close to finalising PEP 517, and it's not really a good time to introduce a whole new competing PEP for consideration. I appreciate that you have some fairly fundamental disagreements with the approach of the PEP, but I honestly don't think going back to square one on a new PEP is the right approach. You're asking for a significant delay in acceptance of either PEP, while we start the review process over again. At the moment, I'm strongly inclined to vote -1 to this new PEP simply because we were so close to consensus on PEP 517, and I don't want to see that progress lost (and potentially the whole thing shelved because people get burned out on the debate). Please consider rephrasing your proposal as a set of points of difference with PEP 517 - preferably just the points that haven't already been discussed (e.g., we've already had the debate on "Add the option to declare an operation unsupported by returning NotImplemented" - what's different in your new proposal?) IMO that would be more productive. Thanks, Paul