Oops! I thought 3.3 was already out. I see it's only a release candidate.
Get this into your head - Python has a different development model than C. There is no standards body, or requirements for backwards compatibility. Anyone who gets into Python thinking that there will be full backwards compatibility is fooling themselves.
Those who want backwards compatibility can do so on one of several ways: 1) keep using the old code and don't upgrade, 2) contribute time, effort, and funding to the core developer team in order to implement backwards compatibility, 3) fork and maintain your own version of the source, 4) make your own run-time hooks to convert old-style Python code to the new-style runtime, or 5) create a new version of Python which does have that backwards compatibility.
I know that REXX and a few other languages have made a point of backwards compatibility even as semantics change. They have different goals, and a different funding model than Python. If enough people disagree, then those people can take the existing Python code base and run with it. But that's not happening. (I think there are some unofficial patches with VC2010 support, mostly used for internal company builds.)
There's, what, a few score people working part time in Python code development? Even Guido works on it only half time. How do you expect that small of a team to pull off a clean 3.0 release without making mistakes? The 3.0 release had a new io system, which was a lot slower than 2.x. There were a lot of bugs, like unicode filenames, which had to be figured out, where previously it was the responsibility of each developer to figure out the Unicode issues.
"Can you help explain this one to me? Why is it ... impossible for Python 3 to have just a couple "from __past__ import" features?"
That's an easy one. Lack of resources. The Python code developers did not want to maintain both old-style and new-style class implementations. They used Python 3 as a way to get rid of old-style. As a consequence too, it means that I can stop putting in the silly 'object' in "class Spam(object):", which was the Python 2 way of indicating that I wanted a new-style class. If 5 people said that they were willing to support old-style classes, and showed that they were committed to doing so for many years, then there may have been a different decision.
You can see that even in the PEP 3000, written during the 2.6 days: "But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteerstamina." (Emphasis mine.)
So many other things had deeper semantic changes, like dict.keys returning a view rather than a list, that a simple syntax change is trivial. I don't think a "from __past__ import comma_exceptions" would have had much benefit. I can be wrong, but that's exactly the thing that the 2to3 converter could handle, and there are patches to make distutils convert 2.x code automatically and import hooks to do that transformation at run-time. One such is pymolurus.blogspot.com/2012/04/pep-414-like-import-hook-for-python-32.html . It isn't a catch-all solution, but that approach could help some people.
BTW, as far as I can tell, clang does not support K&R C.
"Get this through your head": the question here is about whether Python still has a chance of being successful, not whether they are bad people for what they did. My argument is firmly on the "no": Python is in decline after years of stagnation caused by a fork in their effort and I believe that they could have done some things differently at little effort to have had better chances.
Personally, I don't even have skin in the game anymore: I am now using Clojure, and am piecemeal porting my code over. This is actually an easier time than the brutal experience I had dealing with Python's / operator change (which I adopted ahead of schedule, thinking it would help me: all it did was hurt me as my code no longer could be used on 2.5).
I thereby wonder: what are you defending? Do you think Python is succeeding? That in another couple months we are going to suddenly hear of a massive turnaround? That it will still be relevant in another two years when 3.3 is fully deployed everywhere and most libraries might be Python 3 compatible? What is your overall position?
You asked me a specific question. I said that the reason is the lack of resources. I didn't realize that we were talking about the decline and fall of the Python world.
I remember reading "Decline and Fall of the American Programmer." And "Rise and Resurrection of the American Programmer." It's a special kind of consultant who can get paid both coming and going.
Python is in decline? How do you reckon that? In my work, Python is the de factor high-level language for chemical informatics, molecular modeling, structure visualization, and the like. This is much improved over the last 10 years, and won't be dying in as short a time-span as two years in the future. No, most projects haven't migrated to Python 3. Yes, it will be annoying. So was porting client code from IRIX to Linux. That happens.
Really, you need to plan for it. And it sounds like you didn't plan for the division operator change. The ideas of that change first surfaced during user testing under the 1.x days, with Alice. That change decision was publicized in spring 2001, with PEP 238. The "from __future__ import division" was made available in Python 2.2. The runtime even has the -Q option so you can tell it to print warnings wherever there's a problem. The nice thing about this change is that it's purely a syntax issue which can be handled on a per-module basis, and mixed with modules which weren't compiled this way.
These all worked for 2.5, so what was the problem you experienced?
What I'm "defending" is my sense that Something is Wrong on the Internet. It sounds like you're doing things the wrong way. You expect certain behaviors which were never promised or implied, you don't read the update notices, and you don't use the tools which help you achieve the goals you want. No wonder you get so frustrated with Python! But I don't see what the Python developers could have done better, given the resources they had, and given that they care about goals that do not interest you.
You're going to run into the same problems with Clojure. Looking now, it seems that 1.3 broke code. Some things were removed, there were changes to the contrib namespace, and some third-party modules didn't work. Various places say it was a hassle to deal with. Sound familiar? How are you sure something like that will never happen again?
> I didn't realize that we were talking about the decline and fall of the Python world.
The article is called "I Am Worried About The Future Of Python" and the specific thread I chose to participate in directly described a way that the Python 3 schism was contributing to the concern (WinRT support). To quote the lead comment for this thread: "I definitely feel like Python qua programming language has become a missed opportunity in many ways".
I then provided my experience, as someone who has been developing for over 20 years in numerous languages (even designing them and teaching them in a university setting), of a unique set of challenges and mistakes that I see Python having run across--a perspective that one reader called "a brilliant if unpopular analysis"--and yet I'm now simply being dragged into the same defensive argument that comes up whenever the 2/3 topic is breached: to turn it into a very personal attack against me and my abilities led by highly inflammatory and insulting wording like "get this into your head", quite despite the fact that I am hardly in the minority with regards to these overall opinions.
Regardless, I am hereby so confused as to what conversation you feel you are participating in that I am just going to bow out: thank you, regardless, for taking the time to respond.
(Oh, I will respond to the semi-unrelated Clojure discussion, as I should probably make certain I don't inadvertently cause them problems: I do not use third-party libraries written in Clojure, as there is really no need given that all of Java is accessible; this already stops most of these problems. Also, the way Clojure 1.3 broke code is closer to the way Ruby 1.9 broke code--a change I stated elsewhere in this thread was a non-issue for the Ruby projects I'm involved in--than the way Python 3 broke code, and was in fact even less of an issue than that.)
I deliberately used the inflammatory phrase "in your head" because you used the phrase "What really seems to happen with Python is that people get it in their heads "developers should not be using this old feature"". The 'people' you are talking about there are the Python core developers. Those are specific people, not abstract entities. I figured that since you used that phrase with them, then I would reverse it, when saying that that wasn't the point.
I've been using Python now for 15+ years. I've read articles about bemoaning the lost opportunities of Python for almost as long. It needs static types otherwise all is lost. It needs tail recursion otherwise all it lost. It needs macros, it needs to get rid of explicit "self", it needs blocks, ... and so on. People thought for a while that Python development was proceeding too fast. There was the language moratorium so others could catch up. Now you say it's going too slow.
If you want to give me specific details about how Python is losing in popularity, please do. You haven't. Nothing I've seen tells me that there's anything more than the usual churn of people moving in between languages, of hipsters talking about the language de jour, of industry people insisting on certain trends. But what you've written describing your experiences with Python's 2-3 transition does not mesh with my own experiences and readings of the experiences of others. How did the change in division cause problems? Why weren't the existing mitigation mechanisms good enough for you?
I truly am going to stick to my word and ignore the rest of your commentary about Python: there is a long thread with a lot of context started by an article that is at least attempting to disagree with your premise; the things you are asking me to explain are thereby all "assumed state" for this tiny sub-part of the conversation, so you can take up your issues with someone up-thread who might feel less insulted by the overall direction of the argument you are making.
However, I will defend my wording, as I think that is unrelated: the phrase "once you get it into your head that" (even with that direct "you", rephrased from "people get the idea into their heads", about others) is a statement about the virility of the idea that someone now believes; in contrast, "get this into your head" is a direct command given to a person used to indicate that they are being dense and thereby are unable (or unwilling) to understand the idea in question.
To make this distinction more clear, you can look at something generally considered positive: "once saurik gets it into his head that something should be built, he builds it" or "people get the idea in their heads that things should be built, and then they actually build them" are both fine; "get this into your head: once you determine something should be built, you should actually build it" is both harsh and patronizing: it is an entirely different concept for the sentence, used as an attack.
As someone who started this sub-thread I have to say I read it with pleasure: it is informative and broad, I learned some from it, and I wanted to thank you, saurik, for your input and perspective, even though I don't fully agree. I have nothing to say ad rem, at least nothing that wasn't said already, but I wanted to comment on that unfortunate phrase. As I see it, there was no malicious, "harsh and patronizing" intent behind it; I agree that it was not particularly polite, but I feel it wasn't very brutal an attack either. So please, don't hold it against your adversary (or, God forbid, Python community) or at least please try to not be offended - I'm almost 100% sure it wasn't meant to be offensive in the first place.
Get this into your head - Python has a different development model than C. There is no standards body, or requirements for backwards compatibility. Anyone who gets into Python thinking that there will be full backwards compatibility is fooling themselves.
Those who want backwards compatibility can do so on one of several ways: 1) keep using the old code and don't upgrade, 2) contribute time, effort, and funding to the core developer team in order to implement backwards compatibility, 3) fork and maintain your own version of the source, 4) make your own run-time hooks to convert old-style Python code to the new-style runtime, or 5) create a new version of Python which does have that backwards compatibility.
I know that REXX and a few other languages have made a point of backwards compatibility even as semantics change. They have different goals, and a different funding model than Python. If enough people disagree, then those people can take the existing Python code base and run with it. But that's not happening. (I think there are some unofficial patches with VC2010 support, mostly used for internal company builds.)
There's, what, a few score people working part time in Python code development? Even Guido works on it only half time. How do you expect that small of a team to pull off a clean 3.0 release without making mistakes? The 3.0 release had a new io system, which was a lot slower than 2.x. There were a lot of bugs, like unicode filenames, which had to be figured out, where previously it was the responsibility of each developer to figure out the Unicode issues.
"Can you help explain this one to me? Why is it ... impossible for Python 3 to have just a couple "from __past__ import" features?"
That's an easy one. Lack of resources. The Python code developers did not want to maintain both old-style and new-style class implementations. They used Python 3 as a way to get rid of old-style. As a consequence too, it means that I can stop putting in the silly 'object' in "class Spam(object):", which was the Python 2 way of indicating that I wanted a new-style class. If 5 people said that they were willing to support old-style classes, and showed that they were committed to doing so for many years, then there may have been a different decision.
You can see that even in the PEP 3000, written during the 2.6 days: "But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina." (Emphasis mine.)
So many other things had deeper semantic changes, like dict.keys returning a view rather than a list, that a simple syntax change is trivial. I don't think a "from __past__ import comma_exceptions" would have had much benefit. I can be wrong, but that's exactly the thing that the 2to3 converter could handle, and there are patches to make distutils convert 2.x code automatically and import hooks to do that transformation at run-time. One such is pymolurus.blogspot.com/2012/04/pep-414-like-import-hook-for-python-32.html . It isn't a catch-all solution, but that approach could help some people.
BTW, as far as I can tell, clang does not support K&R C.