hmmm. Google does not seem to agree. Your assertion is a wish not a fact. Dogmatic 3.x people are being shown, yet again, the uncomfortable, brutal truth, that 3.x is not happening in science.
Seriously. If you're advising someone considering Python on the 2 v 3 question today, how can you not tell them that possibly one of the most important new machine learning libraries, only works on 2.7.
First off, 3.x is happening in science. I'm a scientist, and I use 3.x, and as of this fall, every single scientific package that I use has been ported to 3.x. Using @ for matrix multiplication is also a pretty big deal to me.
It's worth remembering that most scientists don't do any machine learning, because it's not all that useful in many domains. A lot of science is trying to find an explanatory model for the observations. Machine learning is much better at finding a good predictive model for the observations that may not offer any insight to what is happening behind the scenes.
Yes - I have also moved (a holdout library was ported recently). I even liked it. But here I am thinking about moving backward again after having crossed that rubicon.
Three's problem is that even if 95% of stuff is on it, basically 100% of stuff is on 2.7, including brand new stuff. Let's say you use 10 libraries on average and 95% of libraries have been ported. The odds of having one library missing are still 40%! (1-0.95^10) This ratio goes up the more specialised your work, or the greater your investment in legacy, which is why most 3.x people are generalists/web where they cannot understand the 2.x position. For me this Tensorflow library transports me right back into exactly that 40% problem. That problem does not exist the other way around unless you at all costs need to use Asyncio instead of something that's already been there for years.
In my case I'm going to persevere and put 2.7 back into a virtualenv or something but it's really not ideal and my point is still that if 3.x gave science/engineering people something properly compelling (@ operator is not enough in my view) then the above problem would not be happening.
For example a difficult-but-possible megawin would be to put GPU computing natively into Python. GPU is more than 50% of the compute silicon in most computers nowadays (Iris 6200 uses up 50% of die size in recent Intel core i7). If you include multicore and discrete GPU then standard Python is only targeting about 10% of the available compute silicon in a modern PC! Imagine how very rapidly everybody would move if there were a GPU-enabled Numpy array in 3.6.
