>> No, only the ones that didn't cause backwards incompatibilities, >> and broke existing packages. > > This is impossible. I can point you to some third party project that > can break if you touch some distutils internals, like setuptools. > Setuptools also uses some privates global variables in some other > modules in the stdlib FYI.
So what would break if Extension accepted an abi= keyword parameter? >> Lift the freeze. I'm all for replacing distutils with distutils2, but >> I'm not sure whether you will declare distutils2 ready tomorrow, next >> year, or ten years from now. > > Depends on what "ready" means. Included in Python, so that changes become possible again. > If by ready you mean it can be used to replace Distutils1 in a > project, I declare Distutils2 ready for usage NOW. It's in alpha > stage. I want a solid beta before Pycon. > > I would even remove Distutils from 3.x altogether at some point since > setuptools is not Python 3 compatible, and just put distutils2. > > 3.3 sounds like a good target. So will distuils2 be released before that? If so, when? Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
