I very much understand the bit that science is first and code second. I live by the very much same principle at work and we actually have a lot of (terrible) Fortran and C/C++ code around. And we're trying to adopt Python for large parts of of it.

But I'm not sure I follow your argument. I'm not talking about rewriting existing code. I'm talking about building new things. And they should be built in Python 3, because that's the standard that's meant to be used and supported in the future. Learning Py3 doesn't mean you can't maintain existing Python 2 code. It just means that whatever new thing you write is in a future proof setting.

(Btw. As much as people hate on Fortran, there's one thing that beats most other languages - take a 20 or 30 year old codebase and you're not unlikely to compile it and run it on a modern machine. We can't count on that with Python, but Py3 gives us a slightly better chance.)

Well I guess the point of my argument boils down to the problem of changing key functions in established code. Even Fortran when they adopted new standards, old stuff works fine, for the most part. The problem with python is more that it got really popular in the scientific community, because it is relatively fast and extremely easy to write in, but some of the packages were slow to adopt. I think this created a weird scenario where I'm not sure if python2 will ever go away. The scientific world fell in love with python because it was like a free MATLAB, but more useful. And by the time 3 came out there was a lot of code developed that wouldn't port. If we get down to it, I think this is more a problem of porting than anything else. The scientific community has already made headway into 2 and I will admit that we are really slow to adopt. Because of this I think 2 will stay for quite some time. Myself, I don't take the time to learn 3 because if I write in it I'd just confuse my team. I literally can't write in 3 because it'd be detrimental to my job. This is definitely true for a lot of the scientific computing world. There is always an inherent danger to adopting new standards to a language. And python shows where it can turn bad. Because it got really popular and even though it isn't that detrimental to normal python users it is a huge difference in the scientific world.

I will mention that as a more middle ground coder and physicist, scientists are horrible programmers. Horrible. In python I don't see a lot of uses of definitions, so there are A LOT of global calls. I don't think I'm a great programmer, but it is definitely a focus on "programming is a tool" in our sphere. So there is no real care about "future proof" or any of that. The real care, especially in academia, is "can I get this done". Really the only people that care about future proof are the national labs that are building libraries to be used in mass, something like PETSc. But you even get problems there because things like ARPACK have issues, because it is dependent upon LAPACAK (many might not know, but there is a compatibility issue there with the newest versions).

I myself get upset about this. But what are you going to do? I don't disagree with the science first coding second attitude. But there needs to be a conscious effort of making things, at least, more future proof. The problem is no one pays us for that. We get paid for results. We do not get paid for verification, mind you that is an EXTREMELY important part of science. And we don't, usually, get paid for software development, at least primarily (we do if it leads to results). So it is convoluted and this turns into a large argument about a lot of things. But it is nowhere near as simple as "python 3 is supposed to be the new standard therefore we should write in it." Being a tool, we will always work off of previous code base, and we will always learn what the writer (or HOPEFULLY someone that knows a semblance of what the code does) tries to do with the code/library.