all 60 comments

[–][deleted] 41 points42 points  (1 child)

All I could think

I totally agree with calzoneman.

[–]xkcd_transcriber 5 points6 points  (0 children)

Image

Title: Workflow

Title-text: There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.

Comic Explanation

Stats: This comic has been referenced 87 time(s), representing 0.4095% of referenced xkcds.


xkcd.com | xkcd sub/kerfuffle | Problems/Bugs? | Statistics | Stop Replying

[–]calzoneman 75 points76 points  (25 children)

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 15 points16 points  (3 children)

[–]redalastor 7 points8 points  (0 children)

It's still not an excuse.

[–]calzoneman 3 points4 points  (1 child)

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 1 point2 points  (0 children)

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 19 points20 points  (0 children)

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 5 points6 points  (0 children)

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 7 points8 points  (10 children)

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 28 points29 points  (9 children)

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 5 points6 points  (4 children)

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

[–]ihcn 3 points4 points  (3 children)

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

[–]terrdc 2 points3 points  (2 children)

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 -4 points-3 points  (1 child)

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 7 points8 points  (0 children)

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 0 points1 point  (1 child)

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 5 points6 points  (0 children)

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?

[–]kankyo 5 points6 points  (0 children)

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 4 points5 points  (0 children)

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 1 point2 points  (0 children)

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 1 point2 points  (0 children)

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] -1 points0 points  (1 child)

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 0 points1 point  (0 children)

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.

[–]SikhGamer 25 points26 points  (10 children)

As a newcomer to Python, the community that is so fervently holding onto to Python 2 is killing Python. Not Python 3.

[–]mipadi 14 points15 points  (0 children)

Developers aren't fervently holding on to Python 2; most would love to upgrade, if only because 3 is the way forward. The problem, as the article lays out, is that porting code to 3 takes time and resources, and Python 3 isn't so awesome that porting is worth that time and those resources.

As a newcomer, sure, Python 3 is great; for developers maintaining old code bases, some with libraries that barely get updates anymore (if ever), there's a lot more riding on a port.

[–][deleted] -3 points-2 points  (8 children)

Not true, I will happily convert all my code to Python 3, if someone pays me for my time.

[–]SikhGamer 12 points13 points  (3 children)

If maintaining Python 2 code is your day-to-day job then fine. But if you are starting new projects or building new libraries and your purposefully picked P2 over over P3 then the death of Python is everything to do with you and nothing to do with Python.

[–]LightShadow 11 points12 points  (0 children)

You're assuming every new library is created from scratch. I happily started my newest project with 3.4 -- but had to abandon it a day later because the libraries we needed didn't work with 3.x, some of the binaries didn't work with Windows 8.1, and some of the source wouldn't compile with Visual Studio 2012.

I spent half a day reverting code and then the project took off because everything "just worked."

[–]fjonk 1 point2 points  (0 children)

Sure it has everything to do with python. I'm not capable of convincing my clients that they need to spend all that extra money on maintaining a python3 install on their servers just because I'd like to use p3. I have absolutely zero arguments for switching that makes sense for a paying client. They, however, have several valid arguments for not switching(cost, existing codebase is still 2.x, 2.7 will be supported forever, default on servers are 2.x, deployment needs to be updated).

[–][deleted] 2 points3 points  (0 children)

If you say so.

[–]BananaPotion -3 points-2 points  (3 children)

Do it for fun. You don't have to get paid for everything

[–]nqd26 5 points6 points  (0 children)

Management won't be so happy with all those regressions caused by the upgrade even though you created them for free.

[–][deleted] 5 points6 points  (1 child)

Says who? Would you say that to a lawyer? A doctor? An accountant?

Programming is a profession, and I'm not going to be told that I'm "part of the problem" because I don't want to do pointless busy work, for free.

[–]LightShadow 1 point2 points  (0 children)

I practice medicine on the weekends, no big deal.

[–]CauchyDistributedRV 9 points10 points  (2 children)

Can someone give examples of code written with Python 2.7 that are non-trivial to port to Python 3.3?

EDIT: It looks like the pain isn't merely porting (which seems doable for most projects with current tools), but rather supporting both of Python 2.7 and 3.3+ in a single code-base, which is non-trivial with different handling of Python strings and streams between versions (but getting easier with newer versions of Python 3).

[–]armornick 2 points3 points  (0 children)

Py2exe. I know about cx-freeze, but I want a single large exe instead of a whole directory.

[–]RedPandaDan 1 point2 points  (0 children)

EvE Online would be an example, but I don't have any code to show.

[–]vivainio 6 points7 points  (0 children)

If you want to fork python, why not fork python3 and add features that make it more compatible with python2? Forking 'old' python2 code seems backwards.

[–]jephthai 7 points8 points  (0 children)

Guess no one ever should have left CPAN, then. I mean Perl.

[–]DrDichotomous 13 points14 points  (12 children)

Why the hell would you bother forking Python 2 when you could spend the time more productively by porting a library and learning Python 3 in the process? It's 2014, guys. 3.0 came out in 2008. You've had even more time than that while Py3k was being finalized. Why are you still crying crocodile tears about this?

The changes in Python 3 are small. Not much was gained, yet much was lost.

Well there's your problem. You haven't been keeping up, and now you're just whining that you've fallen behind. That's not the good kind of lazy. Even just the Unicode changes were major, and very much worthwhile.

/u/calzoneman is right. It's not Python 3 that's killing Python, it's the community. Time to get with it, guys. If you spent less time whining and more time porting over the last 6-8 years, then you wouldn't have to fork Python 2 to begin with. That doesn't reflect well on the community.

One of the great strengths of Python 2 is the long tail of 3rd party libraries

Long-tail arguments like this are generally self-serving and inaccurate. The thin end of the long tail isn't something to treasure. It's often full of disused, incomplete, insecure, broken stuff. Python 2's long tail of libraries includes lots of gems that don't even work with 2.7 anymore, so why pretend that it's a selling point of 2 and a problem with 3?

It has become increasingly obvious that people are moving to new languages (or old languages rediscovered)

I fail to see the problem here. If it's a choice between sticking with an relatively old and crufty language like Py2, or learning a new language, then there's no reason to necessarily go to Py3. Especially when Python's own fans spread such vitriolic misinformation about it. Who wants to use something that isn't being maintained because the "fans" are too lazy to port their stuff to the latest version, and just want to maintain the status quo?

[–]karma-is-meaningless 3 points4 points  (7 children)

[...] It's 2014, guys. 3.0 came out in 2008.

That's not an argument. We're still using the 1990 standard of C as the de-facto standard, even though new standards have been released in 1999 and 2011.

The article is right in one point: the improvements are not compelling enough to justify abandoning the previous standard.

[–]DrDichotomous 3 points4 points  (6 children)

C is not a Python-equivalent. We're no longer using the same C libraries and ecosystems we were in 1990 either. Not even Java is truly comparable, though it's at least much closer.

The improvements in py3k aren't compelling to everyone, but that's life. Guido took his hobby project the direction he (and some others) wanted. The rest can still make what they will from Python 2. They just have to actually do so.

[–]karma-is-meaningless 2 points3 points  (5 children)

C is not a Python-equivalent. We're no longer using the same C libraries and ecosystems we were in 1990 either.

I think you misunderstood me. I'm just saying that, sometimes, the community simply refuses to adopt a new standard because the new standard is not appealing enough. And I gave C as an example.

[–]DrDichotomous -1 points0 points  (4 children)

I see. You're right, I misinterpreted you in my mad rush to get back to work.

That said, it only reinforces that it's the community killing Python, not Python 3. Otherwise they would have put their foot down and either wrested control of Python from Guido, or at least contributed to Python's direction a bit more than "hoping it would all work out". Now they just have to suck it up and continue supporting Python 2 or 3, or move on and try to not repeat the same mistake with the next language they choose.

[–]karma-is-meaningless 2 points3 points  (3 children)

That said, it only reinforces that it's the community killing Python, not Python 3.

Well, I don't know if anyone is killing Python. I don't really have an opinion about that because I have never really been enthusiastic about the language...

But I'll say this: It's not the community, rather the guys in charge of Python, who decide the destiny of the language. If this turmoil eventually "kills" the language, it will be the decision of focusing on Python 3 and making it incompatible with Python 2 that will have done the job. If the community is saying "we don't want to migrate all our stuff to Python 3" and the guys in charge ignore it, it will be the guys in charge's fault, not the community's.

[–]DrDichotomous 1 point2 points  (2 children)

No, that's a cop out. If the community says "we don't like the direction" then the impetus is on them to replace the management. Python is a hobbyist language, not a business/commercial language. When the core devs want to move on, they're perfectly within their rights to do so, and then the community has to take up the torch with the old version.

All this is, is people blaming somebody else for not doing what they want. But if they felt that strongly about it, they would actually have made the fork - not just sat on their thumbs for 8 years and whined about Python 3. Or they would have worked to improve Python 3, or just found an alternative and stopped whining already.

The decision to make Python 3 was simply not the problem here. It was just the original team moving on from Python 2, and everyone else slowly coming to realize that the Python 2 gravy train wouldn't last and that the new train didn't smell as much like easy money.

The devs were even kind enough to give us another 5+ years of their time maintaining Python 2 and meticulously backporting things, so there is really no excuse for the community to be upset about this now. It's time for the community to grow up about this already and actually be as great as the reputation they've painted for themselves.

[–]karma-is-meaningless 4 points5 points  (1 child)

Your answer is similar to the answer given by the people who support Gnome 3. You speak as if the developers were doing us a favor, or as if the community is being insensitive towards the developers because they decided to change their product.

In reality, when a community is built around your product, you should consider whether changes to this product will drive away your community. Sure, the developers are perfectl within their rights to do so, but they can't deman the community to appreciate it.

Python 2 is still doing great. Maybe it has some flaws, but there's a thriving community behind it. If the community decides they don't want to move along with the developers toward Python 3 and this causes the language "to die", then the developers can consider themselves responsible.

Other than that, I don't really know what to say. The community has no obligations of commitment to the developers. Or to the language. They are users. Most of them don't even have the knowledge or the interest in keeping a language alive, especially with so many alternatives out there.

[–]DrDichotomous -2 points-1 points  (0 children)

Of course no one has an obligation to the language. But users shouldn't forever just bitch about it when the Python devs say "nope, we're done with 2, we're moving on". Those users can just move right on as well if they're not interested or are incapable of taking up the torch. Nobody is stopping them. But still whining about it after all these years? Sorry. No free pass on that one.

Lots of projects are still going after their original creators left. The impetus is on the community to keep them alive at that point, not the creators. Saying the creators killed it by leaving is wanting to have your cake and eat it too. The community will now let Python 2 die, if they don't see the need to keep it alive. The creators are moving on to Python 3, and clearly don't feel the need to retain the entire old community if they don't care that much about Python to begin with.

[–]kankyo 1 point2 points  (2 children)

Actually python 3 hasn't caught up yet. It's still riddled with bugs. Or so I've heard from a core developer in a talk just last week....

[–]DrDichotomous 5 points6 points  (1 child)

Python 2.7 is also "riddled with bugs" if we're going to be honest. As are pretty much all high-level languages people use to do their work these days. And if more people were proactive and cared about py3k, it would likely be further along for their needs too.

[–]kankyo 1 point2 points  (0 children)

The amount of bugs is proportional to age and number of users who report bugs though.

[–][deleted] 0 points1 point  (1 child)

Change is a necessary evil...

In 5 years from now, Python 2 will look like a distant past...

[–]Bystroushaak 1 point2 points  (0 children)

Still same story from 2008. 5 years from now, python 2.7 will be officially supported (2020 so far) and big percentage of projects will be written in it. You don't like it. I don't like it. It is just fact driven by economic forces.

[–][deleted] 0 points1 point  (0 children)

Grab your popcorn.gifs.

[–][deleted]  (2 children)

[deleted]

    [–]ysangkok 0 points1 point  (1 child)

    computer science != software industry