Clarifying the objection here (since the linked issue is a fairly long one): what I'm against is tightly coupling the pip-gui development & release process to the CPython development & release process when we don't have any compelling reason to do so.

While PEP 434 provides a workaround that helps to keep IDLE consistent across different support branches, it still isn't as robust a development model as folks being able to install an application and try it out on existing Python versions *before* we bundle it with a CPython release. https://packaging.python.org/tutorials/distributing-packages/ provides a general guide on how to publish new packages, and the combination of tox and Travis CI makes it reasonably straightforward to run pre-merge CI testing across multiple Python versions.

Given an independently released pip-gui on PyPI (with its own version numbering and release cadence), then I'd be +1 on bundling that as an optional IDLE addon, ensurepip style. Such a project could also lay the foundation for switching IDLE itself to a similar bundling model, which would allow the need for PEP 434 to be eliminated as well (since bundled applications are already permitted to add new features in maintenance releases).