[Python-Dev] Fix Unicode-disabled build of Python 2.7 (original) (raw)
Ned Deily nad at acm.org
Tue Jun 24 21:54:29 CEST 2014
- Previous message: [Python-Dev] Fix Unicode-disabled build of Python 2.7
- Next message: [Python-Dev] Fix Unicode-disabled build of Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In article <1403625970.6550.133062453.693ECDEA at webmail.messagingengine.com>, Benjamin Peterson <benjamin at python.org> wrote:
If Serhiy wants to spend his time supporting this arcane feature, he can do that. It doesn't really seem worth risking regressions to do this, though.
That's why I'm concerned about applying these 20+ patches that touch many parts of the code base. I don't have any objection to the "arcane feature" per se and I appreciate the obvious effort that Serhiy put into the patches but, at this stage of the life of Python 2, our overriding concern should be stability. That's really why most users of Python 2.7 continue to use it. As I see it, maintenance mode is a promise from us to our users that we will try our best, in general, to only make changes that fix serious problems, either due to bugs in Python itself or changes in the external world (new OS releases, etc). We don't automatically fix all bugs. Any time we make a change, we're making an engineering decision with cost-benefit tradeoffs. The more lines of code changed, the greater the risk that we introduce new bugs; inadvertently adding regressions has been an issue over a number of the 2.7.x releases, including the most recent one. The cost-benefit of this set of changes seems to me to be:
Costs:
- Code changes in many modules:
- careful review -> additional work for multiple core developers
- careful testing on all platforms including this option that we don't currently test at all, AFAIK -> added work for platform experts
- risk of regressions not caught prior to release, at worst requiring another early followup release -> added work for release team, third-party packagers, users
- possibly making backporting of other issues more difficult due to merge conflicts
- possible invalidation of waiting-for-review patches forcing patch refreshes and retests -> added work for potential contributors
- possible invalidation of user local patches -> added work for users
- may encourage use of an apparently little-used feature that has no equivalent in Python 3, another incentive to stay with Py2?
Benefit:
- Fixes documented feature that may be of benefit to users of Python in applications with very limited memory available, although there aren't any open issues from users requesting this (AFAIK). No benefit to the overwhelming majority of Python users, who only use Unicode-enabled builds.
That just doesn't seem like a good trade-off to me. I'll certainly abide by the release manager's decision but I think we all need to be thinking more about these kinds of cost-benefit tradeoffs and recognize that there are often non-obvious costs of making changes, costs that can affect our entire community. Yes, we are committed to maintaining Python 2.7 for multiple years but that doesn't mean we have to fix every open issue or even most open issues. Any or all of the above costs may apply to any changes we make. For many of our users, the best maintenance policy for Python 2.7 would be the least change possible.
-- Ned Deily, nad at acm.org
- Previous message: [Python-Dev] Fix Unicode-disabled build of Python 2.7
- Next message: [Python-Dev] Fix Unicode-disabled build of Python 2.7
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]