Python 3 should escape all historical precedent for adoption of new language major versions that do not maintain compatibility precisely why?

I’m not talking about library incompatibilities that enable new features that make the update worthwhile. I’m talking about changing language syntax in a way that doesn’t actually resolve an ambiguity (as demonstrated by automated conversion success).

Developers aren’t always in complete control of the process of adapting syntax. For example, when Python is adopted as an internal “scripting” language, the developer (of the container) doesn’t have control over the user-provided scripts, and thus moving to an incompatible version is a cost to the user that doesn’t bring benefits to the user. This is hard to coordinate!

When, years after a new language version release, the language development community continues to have to harangue people to try to convince them to move, they should reconsider the source of the problem.

Alex Gaynor – About Python 3

Daniel Veillard December 30, 2013 20:35

making sure my bindings worked for both languages on top for a single release of said bindings has been a PITA frankly, and the demand has been very low. That said it seems the OpenStack guys are switching, so there is some momentum, but breaking an established user base both API and ABI is always a nightmare. Second major screwup in Python land after the I18N UTF16 choice mistake.

H. Peter Anvin December 31, 2013 00:27

UTF-16 is always a mistake.

Kevin Otte December 31, 2013 12:22

Ahh, this sounds so much like the problems with migrating to IPv6, which has been a protocol since 1998! The only difference here is Py2 can be put on life support forever if someone really wants to. IPv4 will eventually fully exhaust.

But, to stay on topic: Does anyone still support PHP4? Upgrades happen. It’s the nature of IT. Someone has to be willing to be the “bad guy” and draw the line in the sand to say “The old version dies on X date.” There will be wailing and gnashing of teeth, and then it will be done.

Michael K Johnson January 01, 2014 18:46

+Kevin Otte You’re really missing the point about the conversion process not being something that will work from a “flag day” perspective when Python has been used (as advertised) as an embedded scripting language, and thus control over the conversion is simply not centralized. Saying “it will be done” is simplistic and not really germane.

There was no need for “wailing and gnashing of teeth” here. The Python development community created this crisis. There was no need for anyone to be a “bad guy”.

Imported from Google+ — content and formatting may not be reliable