On Sun, Sep 20, 2009 at 06:20:41PM -0400, Mark Loeser wrote:
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> said:
> > I agree. But Python 3.1 doesn't have more issues than Python 2.6, so
> > the stabilization is reasonable.
> 
> And how about all of the packages in the tree that use python?  You are
> missing that huge part.  That's like saying libfoo works absolutely
> great, but every single application that links to libfoo now breaks with
> the new release of libfoo-2.0.  The things that use your package are
> just as important when looking to stablize something or to move it out
> of package.mask.

Mark pretty much nailed it on the head.  Before even looking at 
stabilizing py3k it probably would be a good idea to identify what 
libs/frameworks actually *work* with it out of the box.

Keep in mind that gentoo pkging of python ebuilds isn't slotted on 
python version- meaning you wind up with either setuptools for 2.5 or 
for 2.6.  Then you take a look at the larger frameworks like 
numpy and twisted to see if they actually support 3k w/ existing 
releases.  Not a huge number do, at least for actual releases (random 
branches don't count here).

If the big boys don't support 3k yet, it doesn't much matter if the 
small fry do, thus the gain from having py3k stabilized is way less 
and the cost in terms of user annoyance is way larger.

Regardless of the potential portage issue, I honestly don't think the 
state of python libs is at the point that running purely py3k w/ 
single slotting of python pkgs is viable.

Basically what gain is there?  Stabilizing it at this point 
comes off as "whee, we have py3k stabilized!  Now go mask it on all 
of your boxes since not a lot of the useful things play nice with 
it right now!"

My 2 cents.
~harring