|
|
Subscribe / Log in / New account

Development

Debating a "transitional" Python 2.8

By Jake Edge
January 1, 2014

Python 3 has been around for five years now, but adoption of the language still languishes—at least according to some. It is a common problem for projects that make non-backward-compatible changes, but it is even more difficult for programming languages. There is, typically, a huge body of installed code and, for Python, libraries that need to be upgraded as well. If the new features aren't compelling enough, and the previous version is already quite capable, it can lead to slow adoption of the new version—and frustration for some of its developers. Solving that problem for Python 3 is on the minds of some.

Recently, Alex Gaynor, who has worked on core Python and PyPy, expressed his concerns that Python 3 would never take off, partly because the benefits it brings are not significant enough to cause projects and users to switch over to Python 3. After five years, few are downloading packages for Python 3 and developers aren't moving to it either:

Looking at download statistics for the Python Package Index, we can see that Python 3 represents under 2% of package downloads. Worse still, almost no code is written for Python 3. As I said all of my new code supports Python 3, but I run it locally with Python 2, I test it locally with Python 2; Travis CI [continuous integration] runs it under Python 3 for me; certainly none of my code is Python 3 only. At companies with large Python code bases I talk to no one is writing Python 3 code, and basically none of them are thinking about migrating their codebases to Python 3.

That leads to language stagnation at some level, Gaynor said. Everyone is still using Python 2, so none of the features in 3.x are getting exercised. Since Python 2 is feature frozen, all of the new features go into versions that few are using. And it is mostly Python-language developers (or others closely related to the project) who are using the new features; the majority of "real" users are not, so the feedback on those features may be distorted:

The fact that Python 3 is being used exclusively by very early adopters means that what little feedback happens on new features comes from users who may not be totally representative of the broader community. And as we get farther and farther in the 3.X series it gets worse and worse. Now we're building features on top of other features and at no level have they been subjected to actual wide usage.

Gaynor concluded that the divergence of Python 2 and 3 has been bad for the community. He suggested releasing a Python 2.8 that backported all of the features from Python 3 and emitted warnings for constructs that would not work in Python 3. That, he said, would give users a path for moving to Python 3—and a way to start exercising its new features.

As might be guessed, not all were in favor of his plan, but the frustration over the Python 3 adoption rate seems fairly widespread—at least with the commenters on Gaynor's blog. So far, the conversation has not spilled over to python-ideas or some other mailing list.

Alan Franzoni agreed that some kind of transition path, rather than an abrupt jump, is needed.

We badly need smooth transitions, a version where features are deprecated and replacements exist at the same time, so we can progressively improve our libraries. Very few developers are willing to invest their time and resources in porting code to a not-so-used language version, and just one non-py3k-[compatible] library is enough for a project for not migrating to Python 3. It's a chicken-and-egg problem.

David A. Wheeler and others agreed with Franzoni, but "rwdim" felt that Gaynor did not go far enough:

The solution is clear: build a full compatibility layer, not a conversion tool, into 3.x that makes 2.x code run without change and ABRUPTLY stop development on 2.x. Keep the compats backward compatible for 2 releases and then deprecate items that need to die, forcing people to update.

Burn the ship and force people to move ashore or go away.

In addition, rwdim suggested that the Python package index (PyPI) stop serving packages that are not Python 3 compatible at some point. That last suggestion was not well received by PyPI maintainers and others, but it did attract other semi-belligerent comments. For example, "jgmitzen" likens users sticking with 2.x to terrorists (and to the Tea Party in another comment). While perhaps a bit overwrought, jgmitzen's point is that supporting 2.x in the Python ecosystem is taking time and energy away from 3.x—to the detriment of the language.

But "gsnedders" is not sure that a 2.8 really brings anything to the table. In the libraries that gsnedders maintains, things have gotten to the point where a single code base can support both >=2.6 and 3.x, and that should be true for most projects. The more recent feature additions for Python 3 are in the standard library, which means they are available for 2.x via PyPI.

Like rwdim, Sean Jensen-Grey would like to see an evolutionary approach so that a single interpreter can be used with both Python 2 and 3. In another comment, he referenced a March 2012 blog post from Aaron Swartz that outlines his vision of how the Python 3 transition should have worked. It followed the established pattern of adding new features to Python 2.x, which is clearly an evolutionary approach.

But Python 3 set out with a non-evolutionary approach. Python Enhancement Proposal (PEP) 3000 clearly specified a break with 2.x backward compatibility. The question seems to be: is it time to rethink that strategy in light of the slow adoption for Python 3?

It may simply be a matter of time, too. Linux distributions are starting to plan for shipping Python 3 as the default—some already have made the switch. Those kinds of changes can only help spur adoption, though it may still take a while.

In addition, Some don't seem convinced that Python 3 adoption is lagging, or at least that it is lagging as badly as is sometimes portrayed. To start to answer that question, Dan Stromberg has put together a survey on Python 2.x/3.x use. Whatever the outcome of that, though, it seems likely that many core developers are less than completely pleased with where Python 3 uptake is today—and will be looking for ways to improve it.

Comments (13 posted)

Brief items

Quotes of the week[s]

Setting up an email server is a real pain in the ass, and if I didn't have working config files from the previous server, I'd have never got it working.

Email is something that everyone uses, every day. It's intrinsically federated.

We should really be working harder to make it easy for every family or individual to run an email server at home or on their own cloud server.

— Evan Prodromou

I: 00check: Untarring chroot environment. This might take a minute or two.

liar.

— Wouter Verhelst

Comments (10 posted)

GnuPG 1.4.16 released

Version 1.4.16 of the GNU Privacy Guard is out; it contains a fix for the recently disclosed acoustic cryptoanalysis attack. "A possible scenario is that the attacker places a sensor (for example a standard smartphone) in the vicinity of the targeted machine. That machine is assumed to do unattended RSA decryption of received mails, for example by using a mail client which speeds up browsing by opportunistically decrypting mails expected to be read soon. While listening to the acoustic emanations of the targeted machine, the smartphone will send new encrypted messages to that machine and re-construct the private key bit by bit. A 4096 bit RSA key used on a laptop can be revealed within an hour." Note that GnuPG 2.x is not vulnerable to this particular attack.

Also worthy of note: the GnuPG developers have launched a crowdfunding campaign to help with GnuPG 2.1 development, update the project's infrastructure, and more.

Full Story (comments: 6)

Enlightenment DR 0.18.0 Release

There's a new major release of Enlightenment available, DR 0.18.0. This version includes Wayland client support, and much more. See the full release announcement for details.

Full Story (comments: 17)

GnuCash 2.6.0 released

Version 2.6.0 of the GnuCash accounting system has been released. New features include a reworked reports subsystem, the ability to attach external files (receipts, for example) to transactions, a number of new business features, a year-2038 fix, and a relicensing to GPLv2+. See the GnuCash 2.6.0 release tour page for more information.

Comments (none posted)

Darktable 1.4 released

Version 1.4 of the Darktable photo editor is out. New features include an embedded Lua engine for scripting, a number of new mask types, various performance enhancements, a new "waveform" histogram mode, and more.

Comments (3 posted)

Commotion 1.0 released

Commotion is a mesh networking system intended for resiliency in difficult situations; it claims a number of real-world deployments. The 1.0 release has just been announced. "The launch represents the first full iteration of the technology, which makes it possible for communities to build and own their communications infrastructure using 'mesh' networking. In mesh networks, users connect their devices to each other without having to route through traditional major infrastructure." Binary downloads (including a special OpenWRT image and an Android client) are available from this page; source is hosted on github.

Comments (none posted)

notmuch 0.17 available

Version 0.17 of the notmuch email indexer has been released. This update fixes a major bug with SHA1 computation on big-endian machines, so it is thus incompatible with older releases in that regard, even though the old SHA1 computations were incorrect. "This meant that messages with overlong or missing message-ids were given different computed message-ids than on more common little endian architectures like i386 and amd64. If you use notmuch on a big endian architecture, you are strongly advised to make a backup of your tags using `notmuch dump` before this upgrade." Other changes include better handling of duplicate messages, many improvements to the Emacs front end, and a long list of assorted bugfixes and new options.

Full Story (comments: none)

GNU Octave 3.8.0 released

GNU Octave is a Matlab-like interpreted language for numerical computations; the 3.8.0 release has just been announced. "One of the biggest new features for Octave 3.8 is a graphical user interface. It is the one thing that users have requested most often over the last few years and now it is almost ready." Other new features include Matlab-compatible nested functions, named exceptions, and more; see the NEWS file for the full list.

Full Story (comments: none)

Newsletters and articles

Development newsletters from the past two weeks

Comments (none posted)

Gaynor: About Python 3

On his blog, Alex Gaynor laments the adoption rate of Python 3 and wonders if the split 2.x/3.x development model is to blame. "First, I think it's because of a lack of urgency. Many years ago, before I knew how to program, the decision to have Python 3 releases live in parallel to Python 2 releases was made. In retrospect this was a mistake, it resulted in a complete lack of urgency for the community to move, and the lack of urgency has given way to lethargy. Second, I think there's been little uptake because Python 3 is fundamentally unexciting. It doesn't have the super big ticket items people want, such as removal of the GIL or better performance (for which many are using PyPy). Instead it has many new libraries (whose need is largely filled by pip install), and small cleanups which many experienced Python developers just avoid by habit at this point."

Comments (98 posted)

Page editor: Nathan Willis
Next page: Announcements>>


Copyright © 2014, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds