[issue7753] newgil backport

[Ross Cohen]

Ross Cohen <rcohen at 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?

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.

Ross

On Wed, 27 Jan 2010 14:30:20 +0000
Marc-Andre Lemburg <report at bugs.python.org> wrote:

> Antoine Pitrou wrote:
> > More seriously, all the APIs in question (and most of their supporting
> > systems: IRIX etc.) seem practically dead. I don't want to rehash that
> > discussion here, but you can post on python-dev if you want.
> 
> No need... I'm tired of trying to get Python devs on track with
> respect to the PEP 11 process, deprecations, etc.
> 
> >> You could just as well remove them right now: if the GIL doesn't
> >> work on OS/2, then having support for it in the _thread module
> >> isn't really worth much, is it ?
> > 
> > Andrew told me he believed it possible to port the new GIL to OS/2. So
> > perhaps he'll do that before 3.2 is out.
> >
> >> With just NT and POSIX thread support, I think backporting the
> >> new GIL implementation to 2.7 is not possible - we'd have to go
> >> through a standard PEP 11 deprecation process and there are not
> >> enough 2.x releases left for that. It could only be backported
> >> as optional feature, to be enabled by a configure option.
> > 
> > Right. That's what I think too.
> 
> I'll close the issue then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7753>
_______________________________________