This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Yuri.Bochkarev, agriffis, alanjds, amak, cananian, demian.brecht, icordasc, jcea, jhylton, martin.panter, mhammond, orsenthil, r.david.murray, rbcollins
Date 2015-02-19.04:31:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1424320274.44.0.122621618895.issue3566@psf.upfronthosting.co.za>
In-reply-to
Content
It is possible to break backward compatibility in a feature release if the break is fixing a bug.  In this case I think it is in fact doing so, and that in fact in the majority of cases the change would either not break existing code or would even improve it (by making debugging easier).  However, I have no way to prove that.

Often in the cases of compatibility breaks we will do a deprecation of the old behavior in a given release and make the change in the next release.  I'm not convinced that is necessary (or even possible) here.  It would be nice if we could get some data on what the actual impact would be on existing code.  For example: how, if at all, would this affect the requests package?  I *can* give one data point: in an application I wrote recently the affect would be zero, since every place in my application that I catch BadStatusLine I also catch ConnectionError.

I would want at least one other committer to sign off on a compatibility break before anything got committed.
History
Date User Action Args
2015-02-19 04:31:14r.david.murraysetrecipients: + r.david.murray, jhylton, mhammond, jcea, orsenthil, amak, rbcollins, cananian, alanjds, agriffis, martin.panter, icordasc, demian.brecht, Yuri.Bochkarev
2015-02-19 04:31:14r.david.murraysetmessageid: <1424320274.44.0.122621618895.issue3566@psf.upfronthosting.co.za>
2015-02-19 04:31:14r.david.murraylinkissue3566 messages
2015-02-19 04:31:13r.david.murraycreate