Re: [Python-Dev] [Python-checkins] r86264 - python/branches/release27-maint/Lib/distutils/sysconfig.py
Remove one trace of Mac OS 9 support (#7908 follow-up)
This was overlooked in r80804. This change is not really a bug fix,
I'm skeptical that this change should be carried out, then. It's easy to argue that this can't possibly hurt (but I can certainly come up with code that will break under that change); however, I fail to see what good it does. Regards, Martin
Do as you like. I won't insist on it being reverted. 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. Regards, Martin
On 11/6/2010 12:33 PM, "Martin v. Löwis" wrote:
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. 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. If I were going to maintain 2.7 for several years, I would want to have the benefit of gradual improvements that make maintainance easier. Applying such a cleanup to 3.1, say, is less necessary because a) the code will soon be end-of-lifed and not maintained much and b) it can be applied to the newer (3.2) branch and benefit that and all future releases thereafter. -- Terry Jan Reedy
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.
You mean, it's ok to break stuff with no gain in 2.7 bug fix releases?
I question whether cleanup on a maintenance branch makes maintenance easier. For example, one may (and I often do) compare the code base of the previous bug fix release with the upcoming one, to see whether any suspicious change accidentally was backported. Code cleanup is in the way of such analysis, making maintenance more difficult. Regards, Martin
On Sun, 07 Nov 2010 09:01:22 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
It certainly does when using svnmerge. You can have many merge conflicts if cleanups on the dev branch aren't backported to the bugfix branches. Regards Antoine.
[Martin]
FTR, it was documented in PEP 11 as removed in 2.4 (but not in 2.4’s whatsnew).
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.
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
Do as you like. I won't insist on it being reverted. 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. Regards, Martin
On 11/6/2010 12:33 PM, "Martin v. Löwis" wrote:
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. 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. If I were going to maintain 2.7 for several years, I would want to have the benefit of gradual improvements that make maintainance easier. Applying such a cleanup to 3.1, say, is less necessary because a) the code will soon be end-of-lifed and not maintained much and b) it can be applied to the newer (3.2) branch and benefit that and all future releases thereafter. -- Terry Jan Reedy
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.
You mean, it's ok to break stuff with no gain in 2.7 bug fix releases?
I question whether cleanup on a maintenance branch makes maintenance easier. For example, one may (and I often do) compare the code base of the previous bug fix release with the upcoming one, to see whether any suspicious change accidentally was backported. Code cleanup is in the way of such analysis, making maintenance more difficult. Regards, Martin
On Sun, 07 Nov 2010 09:01:22 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
It certainly does when using svnmerge. You can have many merge conflicts if cleanups on the dev branch aren't backported to the bugfix branches. Regards Antoine.
[Martin]
FTR, it was documented in PEP 11 as removed in 2.4 (but not in 2.4’s whatsnew).
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.
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
participants (4)
-
"Martin v. Löwis" -
Antoine Pitrou -
Terry Reedy -
Éric Araujo