On Thu, Feb 7, 2013 at 6:45 AM, Éric Araujo <mer...@netwok.org> wrote: > Bug fixes are possible; changes to keep working with Python (i.e. pyc > files are generated in pycache directories after 3.2); changes to be > able to build on current OSes (e.g. following Mac dev tools location > change, introduction of Debian multiarch, etc.). > > Some bugs have been here for so long that everybody depends on them or > work around them, or they would be extremely painful to fix (e.g. in the > option parsing code) for little benefit, so they are wontfix. > > Cleanups, refactorings and improvements were banned by the feature freeze.
I think the points to be clarified are that *new* internal APIs (including new commands, like bdist_wheel) are legitimate in a feature release, and internal changes which don't affect APIs (like some of the tweaks Dave Malcolm and I made to try to make building Python 3 RPMs on RHEL 6 with bdist_rpm less broken) are legitimate in maintenance releases. distutils is going to be around for a long time for backwards compatibility reasons, so if people want to improve it within those constraints they should be allowed to - we just need to be extra careful with maintenance releases, by treating even nominally internal APIs as if they were public. The current interpretation of the situation as a complete "no few features" freeze is overkill, when the setuptools/distribute developers will have plenty of time to send up warning flares during the alpha/beta/rc cycle. An appropriate rule would be more like "no major refactorings of distutils internals" (which may indeed mean distutils never supports metadata versions past 1.1). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
