PEP 360: Point to the Experts Index

[AA-Turner]

xref: #2270 (comment)

cc @gvanrossum

A

[CAM-Gerlach]

LGTM, thanks @AA-Turner

Changed my mind; I think better to not erase Fredrik after his passing

[CAM-Gerlach]

If we feel anyone might still be confused stumbling across it (even after we remove the mention in the current dev guide), we could add a note stating that the PEP is obsolete/no longer in force at the top.

[AA-Turner]

Please don't merge this until it's updated per new discussion in the linked issue (can't find the convert to draft button on the GH mobile app)

A

[CAM-Gerlach]

Please don't merge this until it's updated per new discussion in the linked issue (can't find the convert to draft button on the GH mobile app)

I marked it as draft (its hard enough to find on desktop, even if you know exactly where to look) but you could also use the in-progress label as a stopgap, FYI.

[AA-Turner]

This is blocked on python/devguide#802 (// the EI noting that Expat is externally maintained).

A

[AA-Turner]

I considered marking the PEP as "superceded", but "superceded-by" requires a PEP number rather than a generic link, and I don't want to change PEP 1 even more!

A

[CAM-Gerlach]

I considered marking the PEP as "superceded", but "superceded-by" requires a PEP number rather than a generic link, and I don't want to change PEP 1 even more!

It could be marked Withdrawn, with an appropriate note, as some old, no longer updated/relevant PEPs have, since its a Process PEP and the "process" is no longer used. But its marked "Final", not "Active", so not sure if worth changing the state now.

PR was redone

[gvanrossum]

I'd like a SC member to weigh in here.

[CAM-Gerlach]

I may be wrong, but I'm not sure this was really the intent of what @gvanrossum and I were suggesting. This PEP wasn't an experts list, it was a list of modules maintained outside the stdlib, a practice which (as the note states) was later determined to be dangerous and prohibited for any new modules, with a few modules being grandfathered in for a time (and nowadays all are maintained in the stdlib). Therefore, the PEP is obsolete in its own right, because the "process" it covers is no longer used, relevant or even allowed, not because the Experts guide replaced it.

[CAM-Gerlach]

Suggestion superseded, see revised suggestion below

.. note:: The modules listed here are now maintained in the standard library
          and no new ones will be added, so this PEP is of historical interest
          only. See the `Experts Index <https://devguide.python.org/experts>`__
          for an up-to-date listing of modules and their associated experts.

[JelleZijlstra]

This is not quite true, expat is still maintained externally.

[AA-Turner]

Suggested change

	.. note:: The `experts index <https://devguide.python.org/experts>`__ in the
	Python developer's guide obsoletes this PEP.
	.. note:: This PEP is obsolete, as new non-provisional standard library modules are maintained internally. See the `place to be determined` for a list of remaining externally managed modules.

Not word wrapped. Is this more in keeping with what you were thinking of? Intentionally didn't specify where the "list of remaining external modules" will be, so that we can discuss the wording apart from the proposed location.

A

[CAM-Gerlach]

This is not quite true, expat is still maintained externally.

True, libexpat is maintained externally, but technically it is a C library (as clarified in the existing PEP text), not a standard library module (as referred to in the note), just like e.g. the zlib library for the zlib module, OpenSSL for the ssl module, and others. Here's a revised suggestion making that more clear.

Suggested change

	.. note:: The `experts index <https://devguide.python.org/experts>`__ in the
	Python developer's guide obsoletes this PEP.
	.. note:: The Python modules listed below (not including the Expat C library)
	are now maintained in the standard library and no new ones
	will be added here, so this PEP is of historical interest only.
	See the `Experts Index <https://devguide.python.org/experts>`__
	for an up-to-date listing of modules and their associated experts.

Is this more in keeping with what you were thinking of? Intentionally didn't specify where the "list of remaining external modules" will be, so that we can discuss the wording apart from the proposed location.

Not exactly (again, sorry)—as Guido mentions, its not completely true, since several recently added modules are maintained separately, and I really don't think we should block clarifying that the PEP is unmaintained and "of historical interest only" on having to create a replacement, which is a non-trivial task (especially if we include third-party libraries wrapped by standard library modules, which will require a fair amount of work to track down).

[CAM-Gerlach]

@JelleZijlstra @AA-Turner @gvanrossum Are we okay with submitting the above revision to the SC, or do you suggest making further changes? Or, what specifically do we want to ask the SC to approve/opine on here?

[AA-Turner]

Not exactly (again, sorry)—as Guido mentions, its not completely true, since several recently added modules are maintained separately, and I really don't think we should block clarifying that the PEP is unmaintained and "of historical interest only" on having to create a replacement, which is a non-trivial task (especially if we include third-party libraries wrapped by standard library modules, which will require a fair amount of work to track down).

Hmm OK. My challenge then is why the "see the Experts..." is relevent, if we're not updating it to contain externally maintained modules. A simpler / smaller change would be:

Suggested change

	.. note:: The `experts index <https://devguide.python.org/experts>`__ in the
	Python developer's guide obsoletes this PEP.
	.. note:: This PEP is for historical interest only, and does not reflect the current state of externally maintained modules.

It does feel odd to remove this though as the supposed listing whilst not creating a new home, although I note the scope widening significantly for little marginal benefit.

A

[CAM-Gerlach]

Suggested change

	.. note:: The `experts index <https://devguide.python.org/experts>`__ in the
	Python developer's guide obsoletes this PEP.
	.. note:: This PEP is of historical interest only, and does not reflect the
	current state of externally-maintained modules.

Add line breaks, hyphen and fix word ("for" -> "of").

Hmm OK. My challenge then is why the "see the Experts..." is relevent, if we're not updating it to contain externally maintained modules. A simpler / smaller change would be:

I was quoting you 🤣 In all seriousness, fair point; I was considering removing it but kept it from your original since it does list the current maintainers of the modules listed in the PEP. But that's not terribly important.

It does feel odd to remove this though as the supposed listing whilst not creating a new home, although I note the scope widening significantly for little marginal benefit.

Yeah, though it doesn't actually "remove" anything, it just makes the current status of the PEP clear. I agree that its not all that important either way, to be honest—the main source of my confusion was it being linked in the devguide, and python/devguide#802 fixes that.

[CAM-Gerlach]

I'd like a SC member to weigh in here.

@gvanrossum Should we open a SC issue, @ them or just wait for Brett to see this?

[gvanrossum]

[...] it was a list of modules maintained outside the stdlib, a practice which (as the note states) was later determined to be dangerous and prohibited for any new modules, [...]

Right. There are still some modules being developed that way (and I think there are problems with the development model for those too) but they aren't listed here. I think importlib.{resources,metadata} (one or both).

[AA-Turner]

may be wrong, but I'm not sure this was really the intent of what ... I [was] suggesting.

To quote you "pointing to the experts list in the devguide"...!

In more seriousness, I think the experts list is the best extant replacement, the change I suggested on you PR to the devguide also captures that Expat is maintained externally. We could create an entire new page in the devguide, but I don't see the point in that.

A

[CAM-Gerlach]

the change I suggested on you PR to the devguide also captures that Expat is maintained externally

More specifically, xml.parsers.expat, i.e. the Python wrapper, is maintained within the stdlib, while libexpat that it depends on is an external library. However, this is no different from a number of other modules, like zlib, ssl, etc that don't have this listed, and nor are any more recent modules that have separate "upstream" repos that @gvanrossum mentions (e.g. both importlib_resources and importlib_metadata, though both of those are still hosted under the Python org). So it may be beneficial to note that in the experts index, it is a separate issue from this one.

[brettcannon]

I'd like a SC member to weigh in here.

@gvanrossum Should we open a SC issue, @ them or just wait for Brett to see this?

Issue as you all are so prolific in this repo at the moment I'm having a hard time keeping up on top of everything else. 😅

[CAM-Gerlach]

Sorry about that, @brettcannon , and thanks for putting up with us!

@gvanrossum Want me to open the SC issue? If so, do we want to propose this revision, a different one or just ask for their general opinion on the topic? I'm guessing that given they're all busy people, the more specific of a request we can give them, the better chance we can get timely and unambigous feedback, but you'd know a little bit better than me of course :)

[JelleZijlstra]

I'd suggest giving a very specific request, such as a finished PR that they can say yes or no too. They're busy people and there are more important things for the SC to do than an update to a minor old PEP.

[AA-Turner]

If we can't agree on wording it may simply be better to mark the PEP as withdrawn. I've probably got energy for one more cycle of discussion, but people have survived for a while with 360 being incorrect and technically still active (final).

I think the devguide change // a list of external modules // concrete policy on how external modules are(n't) accepted would be a far more useful investment of time!

A

[CAM-Gerlach]

If we can't agree on wording it may simply be better to mark the PEP as withdrawn. I've probably got energy for one more cycle of discussion, but people have survived for a while with 360 being incorrect and technically still active (final).

Yeah, I think we can agree on the final revision above, but I also don't want to drag this out much more either—the immediate confusion (for me, at least) was solved by python/devguide#802 being merged; I never would have run into this PEP otherwise. If @gvanrossum agrees, I suggest just leaving the PEP as is (it already has the Warning, after all) and closing the PR rather than bothering the SC over it, at least unless and until we have a more substantive proposal.

[gvanrossum]

Yeah, let's leave this alone after all. (Like Brett, I'm having a hard time keeping up. :-)

[CAM-Gerlach]

Hmm, maybe we should fund a project to upgrade Guido with a specializing active compiler that automatically optimizes CAM's long messages down to just the essential bits? But perhaps that's easier to fix at the source level... 😂