Ross Cohen wrote:
> 
> Ross Cohen <rcohen@snurgle.org> added the comment:
> 
> I am confused by this line of reasoning. Is it ok to ignore the
> deprecation process in py3k but not in 2.x? Is it only ok if a core
> developer does it?

It's normally not ok to ignore the deprecation process for 3.x,
since the 3.x branch is in a stable state, just like the 2.x
branch (3.0 and, after some discussions, 3.1 were allowed to
break things).

I don't know why this process wasn't followed for the new GIL
implementation.

It basically breaks compatibility with the other
thread implementations, but does so without actually removing
the support for them in the thread library we're using for
the _thread module.

Perhaps this was simply not known to other developers.

There's also no PEP for the new implementation, which you'd
normally require for any such major change to the internals.

> If the point of 2.7 is to make it easier for apps and packages to be
> ported to py3k, then what would be the point of these platforms moving
> to 2.7 in the first place? It seems perfectly reasonable not to support
> platforms which are never going to care the release. If the platforms
> are broken for 2.7, you'll get that much more warning before 3.2 is
> released so it can be fixed.

Breaking existing applications and ports of Python for 2.7
certainly won't make anything easier for anyone.

For 2.7 we will certainly not allow the above to happen,
since that's the version that's going to be used by most
people for a few years to come.

What we could do for 2.7, is add Py3k deprecation warnings
to the alternative thread implementations, mentioning their
removal in 3.2.