[Martin] >>> It's rather a matter of agreeing when moving forward: IMO, mere style >>> changes, code cleanup etc shouldn't be applied to the bug fix branches, >>> as their only purpose is to provide bug fixes for existing users. >> >> [Terry] >> The omission of the deletion from the 5/5 revision was a bug in that >> revision. If the removal of OS9 support was documented (announced), >> which I presume it was, then one could consider any visible trace >> remaining to be a bug.
FTR, it was documented in PEP 11 as removed in 2.4 (but not in 2.4’s whatsnew). > Well, the question is: can anything break due to the code removal. > In principle, stuff *could* break even by a function that is supposedly > unused, and had supposedly been removed. The problem is that a > supposedly-unused function actually might be used somewhere, in some > context unrelated to its intended usage. It’s known that people do modify distutils.sysconfig._config_vars, a private dictionary; I can imagine some really contrived example of code using _init_mac, the function I removed, to set sysconfig values for Mac OS 9 in 2.7 code. 1% chance, I guess. >> Perhaps the policy on code cleanup should be a bit more liberal for 2.7 >> *because* it will be maintained for several years and *because* there is >> no newer 2.x branch to apply changes to. > > You mean, it's ok to break stuff with no gain in 2.7 bug fix releases? I don’t think Terry was suggesting breakages, just other kinds of cleanup. In this particular case, I think now that I should have followed distutils policy (which is less liberal that the rest of the stdlib). If there are no arguments against it this week, I will revert the commit. Regards _______________________________________________ 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
