Python 3 is killing Python

[Kevin Walzer]

On 7/15/14, 9:00 AM, Chris Angelico wrote:
> The problem isn't Python 2, nor Python 3, nor even the fact that there
> are two Pythons. The problem is that a lot of people don't understand
> when to choose one or the other, don't understand what the promises of
> support are, and (perhaps worst of all) keep hearing FUD about how
> Python 3 is killing Python. And so the confusion perpetuates.
> Eventually the world will get past that, but in the meantime, we have
> to deal with these sorts of storms-in-teacups from people who simply
> cannot comprehend what's going on.

I think it's more than a tempest in a teacup.

The number of language revisions that result in deliberate, code-level 
incompatibility out there is pretty small. People rightly expect that 
code written for version 2.x of a language will continue to work with 
version 3.x, even if 3.x is designed to go in another direction.

I can only think of two widely used languages in the last decade where 
there was this type of major break in binary compatibility: Perl and 
Visual Basic. Perl 6 is kind of a moot point because it's never shipped 
(insert reference to Duke Nukem or GNU HURD here, as appropriate), and 
Perl 5 has not just seen continued development, but invigorated 
development in recent years. But the example of VB is instructive. 
VB.NET is similar, but not identical, to classic VB, and as far as I am 
aware its uptake has not been nearly as wide as classic VB. Microsoft 
was able to force what limited migration we've seen mainly because VB is 
not open source and they can simply drop support for it from Windows.

I've stayed with Python 2.7 because I've seen no benefit in 3.x that 
outweighs the hassle of going through my code line by line to make it 
compatible. As a Mac developer I deal with this kind of code/API churn 
with each release of Mac OS X, and I have no desire to increase my 
headaches.

Though I expect I will eventually update to 3.x, however, like many 
other developers I am also annoyed by the decision to break backwards 
compatibility in Python. The decision strikes me as arrogant. Cruft and 
backwards compatibility are an inevitable part of any mature programming 
language, and maintaining compatibility is important--more important 
than bolting on shiny new features, in my view. If shiny new features 
must be added, they should be added side-by-side with older API's.

I think the Python developers have undervalued the conservator part of 
their role. Yes, they have provided tools to help application and 
library developers migrate their code, but it should not be incumbent on 
third-party developers to re-architect stable, working code simply 
because the language has broken binary compatibility. Defenders of the 
3.x migration portray such developers as laggards, but I see Python 
3.x's failure to silently and successfully import 2.x code as a failure 
on the language's end.

I won't go so far as to say that Python 3 is killing Python. Python will 
survive. But the headaches of migration are substantial, and should not 
be necessary.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com