[Python-Dev] draft pep: backwards compatibility

[Benjamin Peterson]

2009/6/19 Raymond Hettinger <python at rcn.com>:
> Not sure why we need yet another pep on the subject.  Just update PEP 5 if
> needed.

Hmm. I didn't know about that one.

>
> Also, I think there is a certain amount of wishful thinking here.  Ideally,
> we could approve a tiny PEP with just a few bullet points and it would
> eliminate the need for all of the complicated decision making that we
> usually go through.  Ideally, we could make all decisions in advance of
> seeing the facts for a given situation.  ISTM, this pep is wishing away the
> actual complexity of making software design decisions.

I think it should just serve as a backbone and basis for decisions. It
will certainly not eliminate any complex thinking, but hopefully it
will

More importantly, it shows to the community what our policies are and
what they should expect. Exceptions should be exceptional not the
norm.

>
> The policy for 2.x should probably be different than for 3.x.  ISTM that 3.x
> has not been fully shaken out and that possibly many things will need to
> change as users start to report problems.  The text vs bytes issue is
> lurking throughout the release.  The JSON module in particular was affected
> by a half thought out port to 3.0.  And yesterday on #python IRC, one
> developer reported the email package in 3.1 to be unusable and one of its
> maintainers characterized it as being in need of a serious overhaul (meaning
> major API changes).  In the end, there is going to have to be some
> thoughtful balancing between making the needed changes and not hurting the
> existing users.  I don't think a small, general purpose PEP like this one
> can wish that away.

That is very unfortunate. 2.7 may be the last 2.x release, so this PEP
primarily applies to 3.x anyway. We could add a provision for
experimental or unstable modules, but I don't think those should be
released in the first place.

>
> Another sticking point about preserving features across releases arises if
> the feature itself is hazardous in some way (like have a security hole or
> some such).  The contextlib.nested() function was an example.  It didn't
> ever really work as advertised for its intended purpose (it wasn't truly
> equivalent to two nested with-statements) and it presented users with the
> possibility of hard-to-spot bugs.  The bugfix for it was to replace it with
> new syntax.  Unfortunately, the new syntax didn't provide all of the
> functionality of the original.  So, the question arises about whether this
> particular mine should be left on the battlefield.  We resolved the question
> after a long and thoughtful discussion; I don't think that decision making
> process could have been solved in advance by a bullet-point in a general
> purpose process PEP.

I would say that's pretty close to the procedure in the PEP actually:
"Discuss the change. This may be on python-dev, the tracker...."


-- 
Regards,
Benjamin