[Python-Dev] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py (original) (raw)

Éric Araujo merwok at netwok.org
Mon Nov 8 17:00:27 CET 2010

[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

More information about the Python-Dev mailing list