Skip to content

Remove deceased expert and line linking to now-obsolete PEPs with special rules #802

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 26, 2022

Conversation

CAM-Gerlach
Copy link
Member

As discussed on python/peps#2270 , looks like Fredrik "effbot" Lundh, who has passed away, is still listed here.

Also, the list still mentions and links to PEP 291 and PEP 360, stating they contain special rules for some modules. PEP 291 is thoroughly obsolete, being explicitly limited to Python 2, while PEP 360 has not been updated in many years and with any new additions being explicitly prohibited, it presumably never will be, and all the projects currently listed are maintained in the stdlib and no longer active upstream for at least the past decade or more. This was a source of confusion, so given this sentence no longer applies to any developed CPython version, it should presumably be removed.

@gvanrossum @brettcannon

@AA-Turner
Copy link
Member

@CAM-Gerlach The note I proposed in python/peps#2276 requires that the experts index notes that Expat is externally maintained. I also removed Fredrik Lundh from the modules lists:

(Some day GH will allow review suggestions on any line!)

A

diff --git a/experts.rst b/experts.rst
index a245c91e9..a50c5c453 100644
--- a/experts.rst
+++ b/experts.rst
@@ -184,7 +184,7 @@ pydoc
 queue                 rhettinger*
 quopri
 random                rhettinger, mark.dickinson
-re                    effbot (inactive), ezio.melotti, serhiy.storchaka
+re                    ezio.melotti, serhiy.storchaka
 readline              twouters
 reprlib
 resource              twouters
@@ -251,14 +251,14 @@ wave
 weakref               fdrake
 webbrowser
 winreg                stutzbach
-winsound              effbot (inactive)
+winsound
 wsgiref               pje
 xdrlib
 xml.dom
 xml.dom.minidom
 xml.dom.pulldom
-xml.etree             effbot (inactive), eli.bendersky*, scoder
-xml.parsers.expat
+xml.etree             eli.bendersky*, scoder
+xml.parsers.expat     \*
 xml.sax
 xml.sax.handler
 xml.sax.saxutils
@@ -270,6 +270,8 @@ zipimport             twouters*
 zlib                  twouters
 ====================  =============================================
 
+..note:: \* The expat parser is externally maintained by the
+         `libexpat project <https://libexpat.github.io>`__
 
 Tools
 -----

@CAM-Gerlach CAM-Gerlach force-pushed the remove-old-peps-mention branch from 22cad2f to 38fd86b Compare January 26, 2022 19:44
@CAM-Gerlach CAM-Gerlach marked this pull request as ready for review January 26, 2022 19:44
@CAM-Gerlach
Copy link
Member Author

I also removed Fredrik Lundh from the modules lists

Oops, I'd committed that change as a separate commit, but had forgotten to actually push it. Thanks for the catch.

@CAM-Gerlach The note I proposed in python/peps#2276 requires that the experts index notes that Expat is externally maintained.

The issue here is the Python module isn't externally maintained, just libexpat, which is no different from zlib or the other modules backed by external C libraries that don't have this listed, so I don't think this is really necessary here. Also, I've proposed revising the note, as I"m not sure it totally reflects what Guido and I were suggesting, making this less important. Furthermore, as can be seen on the line immediately above, * is already used for a different specific meaning as mentioned in the introduction, so we'd have to use a different symbol to reference it—or, if we do do this, it might be better to just add a short note like `libexpat`_ is externally-maintained...but again, if we do this, we should be consistent and mention it for the other similar modules that are wrappers around external C libraries.

@AA-Turner
Copy link
Member

we should be consistent and mention it for the other similar modules that are wrappers around external C libraries.

Agree on this. Something about cans of worms springs to mind!

A

@CAM-Gerlach
Copy link
Member Author

Agree on this. Something about cans of worms springs to mind!

Yeah, that might be beneficial, but is getting kinda out of scope for this PR. That would require tracking down all the various modules that depend on external ones and nothing them; in some cases tightly coupled to the Python module, while in others much more loosely so, with potentially different libraries that could be linked against it depending on how downstreams do it. So I'd rather not open that pandora's box here, and leave that for a separate discussion.

@brettcannon brettcannon merged commit 255c7cc into python:main Jan 26, 2022
AA-Turner pushed a commit to AA-Turner/devguide that referenced this pull request Jun 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants