> Unfortunately, the current likely answer re updating vanilla distutils to handle the new
> standards is "we won't". The backwards compatibility issues involved are just too hairy
> for us to start enabling by default in the standard library, and I've become convinced
> that coupling the build and installation tools to the language version is fundamentally a
> mistake anyway (hence the bundling approach in PEP 453).

This makes sense.  Given that distutils is still a basic packaging solution included in the stdlib, and no longer under a feature freeze, what kind of improvements do you think it can get?

* Can we switch to SSL with certificate checking?  I think it’s a big yes.
* Can we improve the UI of some commands in a backward-compatible way?  (Existing example: allowing the upload command to send an existing file, instead of requiring to build and upload in one command line)
* Can we add new commands like upload_docs and test (that would just run unittest discovery)?  It may be judged wasted time, if the whole world uses setuptools (but does it?).
* Can we add support for wheel?  Building extensions with the stable ABI?  New version or metadata formats?

> For this particularly case, I don't see any harm in bringing distutils in Py3 back in
> line with Py2, especially if it's also consistent with setuptools.

It’s basically adding code to support comparison of mismatched types, i.e. time and effort to add something similar to a Python 2 design flaw.  (setuptools’ version class is different from both distutils’ classes.)