[Python-Dev] PEP acceptance and SIGs (original) (raw)

Donald Stufft donald at stufft.io
Thu Oct 1 03:58:40 CEST 2015

On September 30, 2015 at 9:14:42 PM, Alexander Belopolsky (alexander.belopolsky at gmail.com) wrote:

On Wed, Sep 30, 2015 at 8:32 PM, Donald Stufft wrote: > > I don’t see any requirement to post PEPs to python-dev if they have a Discussions-To header in PEP 1.

When I faced a similar situation with PEP 495, Guido's advise was "I think that a courtesy message to python-dev is appropriate, with a link to the PEP and an invitation to discuss its merits on datetime-sig." 1 Maybe it is time to clarify that in PEP 1.

An obvious difference is that PEP 495 modifies the standard library and PEP 470 does not (nor do most of the packaging related PEPs, the one that did was discussed on python-dev).

> I don’t really think it makes sense in this case either tbh, PyPI, pip, and setuptools are not under python-dev’s banner. Given that ensurepip is part of stdlib, I am not sure this is an accurate statement.

PEP 453 states:

    The bootstrapped software will still remain external to CPython and this     PEP does not include CPython subsuming the development responsibilities or     design decisions of the bootstrapped software.

It was an explicit decision in PEP 453 that these projects still remain independent precisely for this reason.

Even if it was, did you make any effort to discuss the proposal outside of a small group subscribed to distutils ML?

Did I personally? No.

The discussion that started PEP 470 actually started on python-dev over a year ago and moved to distutils-sig because people told us to take the packaging stuff off python-dev. However, since it was a PEP, all CPython core developers should have gotten notifications for every modification to the text via the python-checkins mailing list, which all Cpython core developers are expected to be subscribed to. In addition to that, it was also posted as an article to LWN towards the begining of the discussion around it 1.

I don't think it's unreasonable to say that if you want a say in how things are changed, then you should be subscribed to the location where changes get discussed, in this case, distutils-sig.

My main issue with PEP 470 is that it came shortly after PEP 438 and replaced it. PEP 438 created a solution that was not very convenient, but possible to implement. With PEP 470, you are punishing the developers who took your advise and created verified external distribution assuming that it would remain available for a foreseeable future. By your own count, [2] 59 projects implemented PEP 438 verification in two years since the PEP was published. You compare that to 931 that remain vulnerable and conclude that the solution did not work. Given that information about PEP 438 features was very thinly disseminated, I think 59 is a large number and it would be appropriate to involve the developers of those packages in the discussion that led to PEP 470.

Two years is not a short amount of time in the current pace of Python's packaging evolution. Honestly though, we tried PEP 438 and the end result was pip's users were regularly confused. In hindsight, PEP 438 was not a very good PEP. It was impossible to implement in a way that wasn't massively confusing to end users and indeed, our issue tracker, and my personal email, and IRC got fairly regular complaints from end users due to the confusing state that PEP 438 left us in.

With my pip core developer hat on, I decided that it was no longer tennable and I fully planned to implement something to replace PEP 438 regardless of if there was a PEP to back it or not (and as an external project, pip is not bound to follow any PEP, our unofficial policy is to attempt to follow all PEPs unless they are harmful or useless). However I decided that it would be a better overall outcome if PEP 438 was replaced with something that didn't have the problems of PEP 438 and to give folks who cared enough to "show up" to discuss it to have a chance to weigh in on it.

I should also mention that it wasn't 59 projects implemented PEP 438 in two years, PEP 438 was explicitly implemented in a way that matched the way that a few projects were already using to get verified downloads. If my memory is correct, there were ~30 some projects that already had PEP 438 compliant URLs so realistically, only ~20 some projects willfully and knowingly took advantage of PEP 438, the rest were just left overs from before. Of those ~20, a handful of them were small projects that were utilities to make PEP 438 easier which aren't really relevant when discussing if PEP 438 was successful or not.

1: https://mail.python.org/pipermail/datetime-sig/2015-August/000262.html [2]: https://www.python.org/dev/peps/pep-0470/#impact

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

More information about the Python-Dev mailing list