Nick Coghlan <ncogh...@gmail.com> added the comment: In https://mail.python.org/pipermail/python-ideas/2017-October/047599.html, Guido suggested managing this as an occasionally updated Informational PEP (somewhat akin to PEP 394), and I think that will actually work fairly well:
* it clearly gives the information PEP level status (which merely being in the developer guide wouldn't) * it means the guidance can be mostly version independent (which would be a source of irritation if the list was in the reference documentation) * it means we can use the same process for amendments as we do for other informational PEPs (a combination of python-dev discussions, bugs.python.org issues, and specific PR reviews) My current thoughts on structuring that: Title: Recommended Independently Updated Python Packages Tone/Audience: I'll aim the PEP primarily at answering the "Why isn't <X> in the standard library?" question, as that helps us keep the list focused on python-dev specific concerns and avoid turning it into a general categorised list of Python library recommendations like https://github.com/vinta/awesome-python The key criterion for something being mentioned will be when the standard library *already* contains comparable functionality, but there's a language version independent third party alternative that even core developers will often use instead. That list is currently: urllib.requests -> requests (pace of change in web standards) re -> regex (technical challenges with backend migration) datetime.timezone -> pytz.timezone (updates driven by IANA timezone database) ctypes -> cffi (build tools should be version independent) distutils -> setuptools (build tools should be version independent) I'll likely also include a list of libraries where version independence is a key feature, so they've never even been proposed for stdlib inclusion, despite their broad popularity: - the six compatibility module - various backport libraries (e.g. importlib2, contextlib2, unittest2) - third party libraries like lxml I'm not sure if or how I'll cover the scientific Python stack (especially NumPy.ndarray being the reference implementation for multi-dimensional arrays), but Nathaniel Smith has some interesting thoughts on that in https://mail.python.org/pipermail/python-ideas/2017-November/047636.html ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31898> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
