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

[Éric Araujo]

[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