| The Python 2/3 problem has created a decision point. Namely, Python3 is sufficiently different for applications supporting distributions. If you are doing Software-as-a-Service hosted webapps, fine, you can choose your platform, but if you are shipping software, you have to make concious choices about usually supporting what the distros have. And the Linux distros are inconsistent. This problem sounds solveable by saying "users, install a newer Python", though this seldom is effective -- and long lifetimes of things such as RHEL 5 (yes, still afield - and some folks have to support version 2) ship versions that are less compatible with Python 3 compatible hacks than newer Pythons. As a result, this intent to "clean things up", I feel, has massively undercut Python's growth rate. Maybe it's not declining, but there's been what feels to be an inflection point. I suppose looking at download curves for hundreds of long-standing PyPi projects relative to the growth rates of other systems could provide this is a thing or not. Anyway, I do love Python. The problem is not the GIL. Most folks who are making web services get by far with a pre-forking webserver (mod_wsgi, etc) and something like celery for backend jobs. multiprocessing is ok enough for some other cases. It doesn't matter whether Python 3 is attractive so much, and that's what I mean about a decision point - the confusion gave people a chance to shop around, and some people are trying things in other languages now. For instance, Go seems misapplied - it has a different expressiveness and domain area. I'm writing a fair amount of clojure, which also feels a bit more low level (sometimes, just in places). But I felt compelled to look around. The crux of the theory is this - changing something singificantly will allow people the opportunity to think is this something they still want to do. I still believe Python strikes a great balance between expressiveness and readability, and it's surpression of "clever" in programming makes it ideal for a lot of problem domains. And it's kind of old enough that people are going to want to look around. Still, I begin to feel some of the directions being made in 3 are out of touch, just as the resistance to some more expressive language features (crippled lambdas, I vaguely recall) were that way. This happens when those that write the language don't neccessarily use the language, and the (percieved) BFDL approach of "fixing regrets" I am not sure it looks after the good of the whole, the way the 2->3 transition happened. Those should have been evolved slowly, keeping things compatible, rather than creating what is essentially a new language. I'm still pleasantly surprised by how widely deployed Python is to the rate at which people talk about it (say, vs Rails), I think a lot of that is because it's NOT complicated, and you don't need to talk about it so much. It's a quiet workhorse. But I've also started new projects in Python 2 - because I've needed them to work everywhere. Python 3 is almost sort of having the Perl 6 stigma to it in my mind, it's available now, but it's made a compatible break that has shaken trust. Since Python 2 is essentially the deployed standard, there's no real reason for most apps that must be distro installable to work on hybrid support - until the distros move to a version that makes it easier to be compatible, it's more important to support where the users are than risk possible bugs and implementation trouble. Resources are better spent elsewhere. |