Python 2.7 is pretty much wart-free compared to every other language out there. If the warts were worse than the cost of going to 3.x, everyone would be on 3.x.
This simply isn't true. Inertia is a huge factor - people justify what they currently do but ultimately the real reason they do it is because that is their habit. Habits are more powerful than cost-benefit analyses, as a rule.
Python 3 would need to be outstandingly and unmistakably better than Python 2 to get the kind of traction you speak of. But Python 3 is merely better.
This simply isn't true. Inertia is a huge factor - people justify what they currently do but ultimately the real reason they do it is because that is their habit. Habits are more powerful than cost-benefit analyses, as a rule.
History proves your habit theory is wrong. Over the years the vast majority of Python projects have been migrating to newer versions. I have been using Python since the 1.5.2 days (1999) and only recently have we have seen this phenomenon of large number of production projects not migrating to newer version.
In the past, projects would run on the latest version or the past 2 previous versions. You are always going to have some projects on the bleeding edge while others are going to lag behind. This worked well for well over a decade. Now the majority of projects are on 2.7 and it will be that way until there is a compelling reason to migrate because at the end of the day whether you like it or not cost-benefit analysis do matter.
You appear to be replying to your own misrepresentation of what I said -- I see no other reason why you would feel the need to assert 'cost-benefit analyses do matter'.
How long will you keep saying this? Maybe Py3 already is the right place to go? Maybe library support is already good enough? Maybe most devs already switched over, and all the good stuff is already happening in Py3 these days?
And if so, why are you still living in the past? I keep thinking that those warts you are talking about, they are not language features, they might be developers...
Surrogate escapes are a terrible wart. Way worse than bytes vs unicode in python 2. There is still no good way to deal with surrogate escapes as far as i know.
I used to abuse Python as a faster, more flexible bash, and only recently have begun using it to its full potential. Looking back there were a lot of things I wrote in bash or awk that would have made far more sense in Python (and which would have been more readable for others). Seemed in my ignorance I always asked if I could do something in bash, never if I actually should. Coming from HPC and architecture stuff, OOP was not exactly my forte, but now I've been learning Python to use as something more than the default shell on many of my favorite applications, and I am actually using it to create true software systems in the form of GUI tools that are robust enough to share. It has also been nice fully transitioning away from DSLs for numerical analysis and embracing Python's growing expertise in it. Numpy and Scipy were at Python 3.0 more or less from day one of its release.
I chose to learn Python from the ground up in earnest a couple of years ago completely ignoring Python 2 and writing in Python 3 from day one. My reasoning was that it was the number in its name was bigger, and I it turned out that I liked the print function better... that was about it. I did not know the politics behind this or why narcissists post "[insert contrarian statement here]" on Medium and end up all over Hacker News. In my experience, there has been nothing I have found I could not do with Python 3 libraries. My needs are not especially pressing, but I feel as though we have the bases covered already. If anything, we need more systems to move by Python 3 as a default. In the Linux world, often the libraries are already there, but they are simply waiting to be packaged. I think the main thing standing between Python 3 and wider adoption is the minutia of the final stages of deployment, and yes, probably a health dose of developer inertia, too. Some of my old scripts from before I started really trying my hand at Python would get hung up on something like how I was invoking urllib2 to get a file. Others needed a single extra line to the effect of var_str = str(var, encoding = 'utf-8'). Furthermore, in the process I learned why libraries like urllib were changed the way they were. If anything I have found that the organization of stdlib objects is more consistent now.
Which is so much easier than dealing with all the crap that Python 3 brought in. Very few people review the APIs in Python 3 now because there are barely any users.
I'll be honest, I'm not a fluent python programmer (I've worked with other people's code and hacked some small things together, but my strengths are in other languages). Currently the discussions about 2 vs 3 are scaring me away from investing time into actually learning the language in depth.
This is my decision as well. Although I have a ton of python experience and have used it on and off since 2.2. Luckily most of my work lies in the web development space so there's no problem finding alternatives and python 2.7 is still great.
Python 3 is the playground of the cpython developers which seem incredibly disconnected from the real world by now. A lot of the APIs on Python 3 are just bizarre and badly reviewed or completely miss real world solutions for the same problems that people made before. This goes well beyond the bytes and unicode issue even though that will continue to be a huge problem until someone replaces Python 3 as some of the bad decisions in it's design are now so engraved in the API that they will never go away.
Importlib for me is a prime example of a project that lost all direction. It's driven by one or two people and they are developing it without any real world experience with it. I pretty much gave up supporting any of that stuff because with every Python 3 version it changed in new ways and at this point it has lost all portability for me as I need to support from 2.x to 3.4.
Another good example is the general stream interface. While you could argue that the streams are byte/unicode problems they in themselves are an API problem more than a unicode problem. I waste enormous amounts of time trying to make streams work well but the new API is just inherently more complex than before for very little benefit. For the user the new streams are definitely more complicated than the old ones.
While not Python 3 related, but there is a whole new packaging infrastructure project going on in distlib which is used by nobody (with the exception of pip which uses the semantic version parsing of it) besides the original creator and maybe a handful of other people.
asyncio thankfully had Glyph overseeing it, but even with asyncio there are not enough users for the library to go into the interpreter. We're already at the point where there is going to be an updated version uploaded to PyPI which raises the question why it's built-in in 3.4 in the first place, if it's going to change in 3.5 again.
This iterative development worked in Python 2 because of two reasons: a) stdlib packages came from outside the stdlib and were iterated there and b) they were developed out of a specific need and people used it. I don't see this happening for anything in Python 3.
Everybody does work across an IO boundary. Python 3 had the idea to hide the boundary from you but that trick did not work, now they added escape hatches in through surrogate escapes and other things and made everything worse in the process.
Most people just produce broken code in Python 3 now because if you don't touch it too much, it seems to work.
Just getting command line arguments is boundary code.
It's an OS issue. CLI arguments and file names are always UTF-16 text on Windows and some unregulated binary stuff on UNIX that may or may not be some text in a system-wide locale that may have been changed by another application through setlocale. Naturally, choosing one approach somewhat breaks the other.
6
u/TankorSmash May 26 '14
The alternative is dealing with those warts that built up. This is a necessary evil!