On Nov 2, 2009, at 11:51 PM, sstein...@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
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
