Some of my views on Naftali Harris's 'Python 2.8'

December 12, 2016

Naftali Harris recently wrote Why I'm Making Python 2.8, which served to also announce his 'Python 2.8' project (which has subsequently been renamed until the dust settles). His goals are straightforward:

[...] because I want to give all the people who use Python 2 access to the Python 3 language features, which I think are actually pretty cool. [...]

His opinions on the whole situation and evolutionary process of Python 3 are a fairly good match with mine, including on the relative (non-)gains to be had from porting perfectly good working code to Python 3. And many of the Python 3 features that his Python 2.8 adopts are quite nice in quiet ways (no-argument super(), for example).

So I ought to really like the idea of this sort of Python 2.8, and to a certain degree I do. But at the same time I don't feel all that interested in it or compelled by it, which has surprised me. After thinking about it for a while I think I understand why I feel this way and thus I have some views.

If you have a Python 2 code base that you're actively developing, changing, and evolving, then the new features are attractive. As you work on the code you'll get a chance to start using them and they'll make your life better, and it might even make sense to do a global refactoring to switch to nicer versions of things across your entire code base. Some of the new features will enable you to do more in your Python 2 code than you could before.

(I'm magically assuming that there are no support or other issues with Harris's version, that everyone loves it and adopts it in place of Python 2.7 and it gets solid support.)

But not all Python 2 code bases are like that. Some are basically static now; they just work and no one is touching them apart from bug fixes (hopefully minor) and other necessary but minimal updates. For these code bases, the big concern with Python 2 is simply whether it will continue to work and work well. You're very unlikely to go through such static code to rewrite bits of it to use new features adopted from Python 3, even if that would make the code clearer, because the current code works even if it's not as great as it could be.

If you're writing new greenfield code from scratch, even Harris concedes that Python 3 is a better language than Python 2 (and I'd maintain better than even his 'Python 2.8'). So you should really use Python 3 for that; it's even better than Harris's work even in the best case for the latter and there is no downside of existing code. I'm reasonably positive about Python 3 for new things after recent experiences.

The reason why I feel only lukewarm about Harris's work is simply that I don't really have any Python 2 code bases that I'm still actively developing. The closest that I come to one is DWiki, and that has only one real feature I expect to ever add to the current code (some form of good tag support, which I haven't done anything on for years). Everything else is essentially frozen, including my other substantial Python program.

(Oh, we have one Django application, but the Python 2 versus 3 fate of that is tied very closely to Django's support or lack thereof for Python 2.)

PS: Regardless of what the official schedule is, I believe that Python 2.7 will stick around well after 2020 and is unlikely to have problems. But if 'Python 2.8' extends that lifetime, it'll save me some amount of hassle and so I'm all for it. And if it wants to improve Python 2.7's performance too, sure, I'll take that as well.

Written on 12 December 2016.
« Realizing that I'm not actively attracted to FreeBSD for my desktop
Vi, movement commands, efficiency, and me »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Dec 12 23:20:10 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.