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
--
https://mail.python.org/mailman/listinfo/python-list
