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
I'm skeptical that this change should be carried out, then. Yes, I asked myself the same question. I had done the svnmerge from py3k, and when I saw that only one change was left, I wondered whether I should commit or revert.
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. This was a private function used on an unsupported platform, this should do no harm. We’ve been bitten by “should do no harm” before though, so I am ready to revert this change (and learn from this :)
Regards
This was a private function used on an unsupported platform, this should do no harm. We’ve been bitten by “should do no harm” before though, so I am ready to revert this change (and learn from this :)
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:
This was a private function used on an unsupported platform, this should do no harm. We’ve been bitten by “should do no harm” before though, so I am ready to revert this change (and learn from this :)
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.
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
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.
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.
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.
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?
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.
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:
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.
I question whether cleanup on a maintenance branch makes maintenance easier.
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]
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
participants (4)
-
"Martin v. Löwis" -
Antoine Pitrou -
Terry Reedy -
Éric Araujo