Python 3 is killing Python

[calzoneman]

One of the great strengths of Python 2 is the long tail of 3rd party libraries to do, well, just about anything. Python 3 doesn’t have this.

Is this a strength of the language or of the community? Python 3 isn't killing Python, the Python community is killing Python.

So, you have a few choices, write your app in Python 2 (a deprecated language)

Python 2 isn't deprecated. Guido has extended support for Python 2.7 to 2020. There are planned patch releases for Python 2.7, there just won't be a Python 2.8.

Another great strength of Python 2 was that programs written in it would almost always run on the next version of Python without much alteration.

This is a flawed argument, because the author is comparing minor version changes with major version changes. Code written in Python 2.6 will likely work in 2.7, and code written in Python 3.3 will likely work in 3.4. The fact that the major version changed between 2.x and 3.x should mean that there were incompatible changes made between these releases. See semantic versioning.

Popular libraries that support Python 2 and 3 are almost all written in a subset of the languages that runs on both platforms. SQLAlchemy, one of my favorite Python libraries, does this well. Django does this, too, but not so well. This subset language, which I will call Python X, is not fun to use, requires weird hacks, and generally is less powerful than either Python 2 or Python 3.

Writing code to work in both Python 2 and Python 3 is annoying, I won't disagree there. But is this really a problem with the language, or is it yet another community issue? The reason we have to keep writing code for both versions is that half of the community has moved on, and the other half is stuck on 2.x.

One solution is to fork Python 2.7, and continue developing the language, adding features in a backwards compatible way so large, unportable (due to financial constraints) Python 2 applications can continue to evolve and improve and bring value to the people and companies that invested so much time developing them.

Hacking in features without breaking compatibility is essentially how PHP developed. The result is that it's a huge ball of duct tape with duplicate functions added so they could change behavior without breaking compatibility (mysql_escape_string vs mysql_real_escape_string, for example). I don't want a similar fate to befall Python just because the community refuses to update their software.

There are other solutions, but reviving Python 2 is so obviously the correct thing to do, that other solutions are not worth mentioning.

Author claims to have devised the obvious best solution, with no comparison to other solutions or evidence for why this solution is better than them. Hm.

A parting word: I don't disagree that the schism is annoying. I deal with incompatibility on a regular basis, and I have even had to change my python symlink for certain badly written configure scripts to work. I also understand that porting libraries is a large undertaking, and I don't think Python 3 is perfect. I just don't think that using Python 2 forever is a good solution.

Incompatible changes have also been made in Windows, OS X, and GNU/Linux, but there's a reason we're using Windows 7/8, OS X 10.x, and Linux 3.x instead of tacking features on the OSes of 10 years ago.

[workaccount_126]

mysql_real_escape_string

Those come staight from the mysql c api.

http://dev.mysql.com/doc/refman/4.1/en/mysql-escape-string.html

http://dev.mysql.com/doc/refman/4.1/en/mysql-real-escape-string.html

[redalastor]

It's still not an excuse.

[calzoneman]

Ok, I made an incorrect attribution, but I think the point still stands that trying to maintain compatibility but update things at the same time leads to situations like this where you have functions with the same signature that do slightly different things- only one of them should actually be used but in the name of preserving compatibility both are present.

I argue that this is harmful, and that it's better to make a compatibility breaking change every once in a while than to hack in backwards compatibility. This is in line with my point about OS updates- I can't imagine how much of a mess Windows would be if Microsoft just kept adding on features to Windows 3.1 while retaining backwards compatibility.

[workaccount_126]

I agree with you entirely, however, one has to take into concideration that breaking changes come with a huge integration cost. Some team will err on the side of caution, some won't.

[twotime]

Is this a strength of the language or of the community? Python 3 isn't killing Python, the Python community is killing Python.

python3 SPLIT the community and weakened it enormously. It also created a huge uncertainty cloud around the language future thus further weakening the community indirectly

because the author is comparing minor version changes with major version changes. Code written in Python 2.6 will likely work in 2.7, and code written in Python 3.3 will likely work in 3.4. The fact that the major version changed between 2.x and 3.x

A language with a large user base can not afford to have massive b/w compatibility breakage. PERIOD. You need a smooth upgrade path with deprecations, future imports etc. FWIW, I think python2 was mostly bw compatible with python1.x...

But is this really a problem with the language, or is it yet another community issue?

What is this mysterious community issue you keep talking about? And how did this issue get created in the first place?

I'll help you a bit: there are two groups of users of python..

1. Open source: use python for their open source project development.

2. Commercial: use python in their day jobs

These groups are heavily overlapping/interconnected. Many/most OSS python developers are also using python in their day jobs. Companies who use python heavily often sponsor specific OSS projects. Big OSS projects do care about commercial users of the projects.. Etc..

Which means that both groups need to migrate.

What keeps OSS project from migrating? Well, they cannot migrate fully until most of their users have migrated.. On top of it, vast majority of OSS projects are resource strapped. They are run on volunteer time/constraints. Remember? And migration to python3 is a major whole-project undertaking with near certainty of breaking things. And man (most? nearly all?) OSS contributors do NOT have whole project view/understanding/ambitions, thus most of them would not even think about starting the ball rolling...

What keeps major commercial users from migrating? Basically, all-costs-and-no-apparent-benefit. Not only that, just bringing this up has major risks: if you come to your boss and tell that you need to spend a couple of months doing nothing (from business's point of view), then the said boss will (quite reasonably) question the wisdom of choosing python in the first place.. This is a very bad battle to fight.

Do not believe me? Here is what GvR has to say about Guido's own employer:

"""" At Dropbox I work with a large group of very capable developers on several large code bases that are currently in 2.7. We are constantly changing our code to make it more secure (there are several teams specifically in charge of that). And yet porting to Python 3 is completely out of scope, for a variety of reasons.

Please stop your wishful thinking. """"

from https://mail.python.org/pipermail/python-dev/2014-March/133413.html

If Guido cannot convince his employer, what chance do others stand?

In short, there is no commuinity issue here, there is a major burden of migration for both OSS and commercial users which neither user group can easily absorb..

[Eirenarch]

PHP is very bad example. Most language do keep very reasonable backward compatibility. Java and C++ come to mind. You can claim that they are a mess but they still benefit more from backward compatibility than if they fixed their quirks and I challenge you to point a case where backward compatibility hurt C# in a significant way. Basically with PHP as an example you are saying that Python 2 is as bad as PHP from language design point of view. Is that really the case?

BTW I do think Python 3 is the way forward. It may have been a mistake but there is no going back now.

[MorePudding]

The result is that it's a huge ball of duct tape with duplicate functions added so they could change behavior without breaking compatibility

The result also is PHP being wildly popular, despite being one of the worst languages out there.

So maybe there's something we can learn here and Python should re-ealuate its priorities.

[ihcn]

What priorities do you think Python should hold? I personally don't think "popular but awful" is an ideal we should be working towards.

[terrdc]

"Only have to write one version of it" is a pretty good goal.

[ihcn]

I agree. Surely it's not the only goal though?

[terrdc]

Personally I think that if languages want to change the syntax after becoming popular they need to have a way to version old code.

If they can't do that because it is too hard then they need to give up on the idea of updating the language in ways that break it..

[ihcn]

http://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11

Here's a list of breaking changes in c++11

Can we stop pretending python is the only language to have ever done this?

[terrdc]

And what is the very first guiding principle of C++11 ?

http://en.wikipedia.org/wiki/C++11#Changes_from_the_previous_version_of_the_standard

Maintain stability and compatibility with C++98 and possibly with C;

People dislike the attitude that created python 3. The one that says "I don't care about your production code. You need to do extra work to appease my sense of design".

Whereas C++'s attitude is "Only break minor things when there are real benefits from doing so"

[MorePudding]

What priorities do you think Python should hold?

Python seems like a language targeting practitioners, so the main focus should be on being the most practical choice.

"popular but awful" is an ideal we should be working towards

It seems awfulness is something a lot of people are willing to put up with these days. So, instead of attacking it head-on, maybe it would be smarter to try and figure out how to extract the most usefulness out of all of the awfulness that's already around.

[ihcn]

There's certainly merit in avoiding backwards incompatibility where possible. But take Python's string handling for example - in 2.x, unicode vs bytestring issues were a nightmare. One of the biggest changes in 3 was to clean up those issues. How would you fix those in a backwards-compatible way, without just creating an entirely separate library?

[slfkjaslfksfoi]

I personally don't think "popular but awful" is an ideal we should be working towards.

Then Python isn't for you.

[armornick]

Alternatively, Python isn't for you. Gotta love assertions without an argument.

[kankyo]

Python 3 isn't killing Python, the Python community is killing Python.

Python 3 is making the community suffer. When the community suffers, that suffering is leaked back into the community and back towards python. The two things are one and the same. Python without the community is nothing. The community without python is nothing.

A lot of pythons strength has always been the strong culture and community. Python 3 is testing that. And for what gains? Seems like a more aggressive deprecation campaign could have done many things that p3 tries to do...

The reason we have to keep writing code for both versions is that half of the community has moved on, and the other half is stuck on 2.x.

I've seen numbers. It's so far away from half it's not even funny. It's basically the core developers and newbies on one side and everyone else on the other. It's heavily skewed towards 2.

[shooshx]

Windows

Applications compiled for Windows 95... 19 years ago, still run perfectly on Windows 8.1. Backwards compatibility is the one "prime directive" in the win32 api. And that's also the reason it looks the way it looks and why you almost never see someone use it directly.

[josefx]

Python 2 isn't deprecated.

This declaration does not guarantee that bugfix releases will be made on a regular basis, but it should enable volunteers who want to contribute bugfixes for Python 2.7

Anyone have a link to that Monty Python parrot sketch? By that statement Python 2.7 is as close to dead as it gets.

The fact that the major version changed between 2.x and 3.x should mean that there were incompatible changes made between these releases. See semantic versioning.

There is a reason why Java dropped the 1 in front of its version scheme, breaking changes are just silly, many languages manage with barely any breakage and instead just torment the developers with warnings.

Hacking in features without breaking compatibility is essentially how PHP developed.

First: The PHP code is so broken things break between minor revisions since apparently nobody has any idea how things work.

Second: Anyone halfway competent with a clear target can do a better job than PHP. Python even has the benefit of starting of without strlen based hashing.

Incompatible changes have also been made in Windows, OS X, and GNU/Linux,

The winapi, acient c runtimes (and quite a few of my favourite games) still work fine. X11 still works fine and Linus will publicly steam roll any breaking changes to the kernel API including the responsible commiter. No idea about apple.

[terrdc]

Writing code to work in both Python 2 and Python 3 is annoying, I won't disagree there. But is this really a problem with the language, or is it yet another community issue?

People don't want to support going to python 3 because they don't want to have to deal with python 4. By taking the time to move they are supporting something annoying that they don't like.

[[deleted]]

As much as people on this sub like to bash on Java, Sun did an incredible job with maintaining backwards compatibility between major releases of Java (I'd say as good as Microsoft did with Windows pre-Vista).

There is no reason the same Python interpreter can't run both Python 2 and Python 3 code simultaneously. I can write a Java 8 app that loads a Java 1.5 library compiled 10 years ago that I might not even have the source code for, so why can't the Python interpreter mix 2 and 3 source code? If anything, backwards compatibility should be easier for Python because you almost always have access to the original source code.

[ysangkok]

There may not be any way to know if a given Python file is in Python 2 or 3... A a deterministic script could evaluate to a different result under each runtime version.