[Python-Dev] Fix Unicode-disabled build of Python 2.7

Ned Deily nad at acm.org
Tue Jun 24 21:54:29 CEST 2014


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



More information about the Python-Dev mailing list