Am 26.03.2014 00:06, schrieb Nick Coghlan:
>
> On 26 Mar 2014 08:32, "Georg Brandl" <g.brandl@gmx.net
> <mailto:g.brandl@gmx.net>> wrote:
>>
>> Am 25.03.2014 23:15, schrieb Nick Coghlan:
>> >
>> > On 26 Mar 2014 01:19, "Brett Cannon" <bcannon@gmail.com
> <mailto:bcannon@gmail.com>
>> > <mailto:bcannon@gmail.com <mailto:bcannon@gmail.com>>> wrote:
>> >> As long as we make it clear we have chosen to change our
>> > backwards-compatibility guarantees in the name of security and have a link to
>> > the last backwards-compatible release then I agree as well.
>> >
>> > I am not sure how this meme got started, but let me be clear: the proposed
>> > policy DOES NOT provide blanket permission to break backwards compatibility in
>> > the affected modules. It only allows ADDING new features to bring these modules
>> > into line with their Python 3 counterparts, making it easier for third party
>> > packages like requests to do the right thing in a cross-version compatible way.
>>
>> We know. That's what we mean by that.
>
> That's not what Brett said - he called 2.7.6 the "last backwards compatible
> release". That's not correct, as even under my proposal, 2.7.7+ will still be
> backwards compatible.
Yeah, I took "backwards-compatibility guarantees" to also mean the "no new
features" guarantee, but you're right that the two can be separated.
That's also the way I took it; not that code would be inherently broken from 2.7.0 -> 2.7.x, but that the "let's stay conservative and add *nothing*" would stop being followed since something in 2.7.x wouldn't work in 2.7.0. IOW I expect (except maybe in extreme edge cases) that unmodified code would work across 2.7 as long as it works in 2.7.0 no matter what happens with this PEP.