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