[Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

Barry Warsaw barry at python.org
Tue Nov 3 14:09:06 CET 2009


On Nov 2, 2009, at 11:51 PM, ssteinerX at gmail.com wrote:

> I agree as long as:
> 	A> 2.7 comes out as soon as possible, even if it's missing helpful  
> porting features.
> 	B> 2.7 will get ONLY new features that make it easier to port to  
> 3.x, not every feature added to 3.x or all you've done is make  
> "Python 2.7, the Python 3 Version." and core developer time will  
> continue to be wasted on Python 2.7 instead of moving forward.

I'm not sure I agree with that core developer time will be "wasted on  
Python 2.7 instead of moving forward".  However, I completely  
understand core developers seeing Python 2.x as a dead end and not  
wanting to work on it.  If that's a real issue, we should acknowledge  
that as a factor in the decision.  This is a volunteer organization  
and if the majority of developers are sick and tired of Python 2, then  
it absolutely makes no sense to slog through a Python 2.7 release.   
I'd much rather take all the enthusiastic energy that decision will  
reclaim and focus it on, oh, Python 3's email package instead <wink>.

>> I also think Guido's call for feature freeze makes a lot more sense  
>> when 2.7 is the EOL.  Let's give people migrating to Python 3 a  
>> nice big stable target to hit.  Improving the stdlib also gives  
>> people a big carrot to move.
>
> Agreed. And specifically NOT porting every shiny new toy from Python  
> 3 back to 2.7 makes sure the carrots are only in the 3.x series.

Python 3's got enough carrots and sticks already.  One huge carrot  
that will never make it back into Python 2 is bytes/strings of  
course.  The huge stick is that Python 2 is end-of-lifed, if not now,  
eventually.  It isn't going to get a reprieve.  Everyone knows that  
everyone will have to get to Python 3.  The question is, what can we  
as a community  do to make that inevitability as easy to swallow as  
possible?

>> I think it's also necessary to give third party library and  
>> application authors as much help as possible to provide Python 3  
>> compatible software.  Putting together Python tools involves so  
>> many dependencies in a fairly deep stack that even one unconverted  
>> library can cause everything above it to stall on Python 2.
>
> And that's one of the reasons my explorations into Python 3 have  
> been limited to pretty much nothing.
>
> I don't have time to do a bunch of work only to find out that the  
> tool I absolutely have to have to finish a project doesn't have a  
> Python 3 version or has been crippled to make a Python 3 version.

Unfortunately, I think we have to do those explorations, fail, hit  
roadblocks, complain, etc. but most importantly identify the packages  
that need to be ported.  Then work with those package authors to make  
the upgrades happen.  And improve Python and Pythonic tools so that  
migrations can go smoothly.

Speaking as a package author, I know how much work it is just to get a  
bug fix release out.  The three lines of code fix means 50 lines of  
test writing, a half a day of documenting, packaging, uploading, and  
announcing.  Porting even one of my packages to Python 3 is a  
significant undertaking which frankly I don't have the cycles for.   
Anything large and complicated is hopeless.  Witness how long and  
difficult it's been just to get a standard library module updated  
(email) and you get a sense of how much work it will be to get an  
entire stack of code onto Python 3.

> BeautifulSoup, which I use every day, is one such product.  Since  
> the crappy old SMGL parser's gone, BeautifulSoup uses the one that's  
> left in Python 3 and it makes BeautifulSoup completely useless for  
> my daily work.
>
> That's not to say I can't fix that one particular project, but  
> customers get cranky when their project is taking longer than  
> expected and "Oh, I'm having to convert a lot of things to use  
> Python 3" doesn't seem to improve their mood much.

I completely agree.  What happens when your application depends on a  
half dozen Zope packages, Twisted, and 15 or 20 other established,  
mature packages?  It's a daunting prospect.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 832 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/python-dev/attachments/20091103/278fa416/attachment-0001.pgp>


More information about the Python-Dev mailing list