I've observed the scientific community to be generally curmudgeonly about software issues overall, so I'd predict that they will be the <i>last</i> group to move to Python 3. So once every other community has moved over (in this order: hobbyists, bleeding-edge startups, tech companies/startups in general, corporate environments), then it will be their turn, and they certainly will because the ecosystem will have completed moving over.<p>As far as 2to3/3to2, that entire process in my opinion will be going away; once you've pegged Python 2.6 as your bottom version, it's straightforward (though not without effort) to produce a codebase that runs in Python 2 and 3 without any changes. I've already done this for my template language Mako, where version 0.7.4 has been enhanced to support Python 2.4 all the way through the latest 3.3 without any 2to3/3to2 step.
Why? One of the interesting things about science is that your results are <i>better</i> if you don't change too much. So if you're using a python 2.4 to do your data analysis and now your re-creating your experiment from 5 years sgo, if you have a new Python and libraries and you get different results, then one of the things you will need to do is put everything back to 2.4 and see if your results changed because of the software or because of the experiment.
Hopefully never. All the new changes might make Python better in the view of a computer language consistency fetishist (or maybe for web apps). But for practical purposes in data analysis things got worse not only because of the broken backward compatibility.<p>Letting major APIs return iterators or views instead of lists just introduces unnecessary complication. Most people doing data analysis don't even know what these structures are but they definitely know lists.<p>Scientists have to deal a lot with bytes or strings of bytes but never Unicode. Python3 treats Unicode as first class citizen as opposed to raw strings of bytes like in Python2.<p>Sometimes you have to convert a lot of clear text data formats and needing to use 'print(x, end=" ")' instead of a simple 'print x,' makes me cringe every time. Printing something is substantial why shouldn't be a statement.<p>Finally the loss of performance in Py3k is the straw to break the camel's back. I use numpy because it is usually faster than the stuff I wrote myself in C. I use python because I got the best performance without having to care much about programming.<p>I want to be able to reproduce results I or other people did 10 years ago. Maybe poeple in 100 years want to do that. A language that breaks backward compatibility for trivial consistency issues is definitely not suited for that. The easiest solution would be to stay with 2.x for ever or choose a more stable language.
Unicode support may be a small thing for scientists, who are usually dealing with numbers rather than strings. But it's absolutely huge for the rest of us, and that alone will drive the big libraries to python3. It'll be slow going - I've essentially stopped work on my biggest personal project as I'm stuck in a mess of libraries that have moved to python3 and libraries that haven't - but unlike with perl6, I haven't seen any major libraries explicitly planning not to support python3.<p>So yeah, 2018 may be a lower bound for the point at which the scientific community moves to python3. But that doesn't mean it won't happen.
Speaking as a scientist: the reason for me is that there are lots of breaking compatibility changes in exchange for very little benefit. The only improvements I would care about -- fixes to the bad GC and broken concurrency system -- weren't and still aren't on the table.
A lot of scientists are working on poorly administered clusters where the installed Python is 2.5 or lower. I've even run into one 2.3 occasionally. Some have versions of libc so old that you can't always compile newer software (as I learned to my horror when I tried to install GHC on the VITAL-IT cluster in Lausanne -- libc on that system is now approaching ten years out of date).
One thing that doesnt receive enough attention is the changes to the Python C-api. References :<p>1) <a href="http://python3porting.com/cextensions.html" rel="nofollow">http://python3porting.com/cextensions.html</a><p>2) <a href="http://docs.python.org/3.0/whatsnew/3.0.html#build-and-c-api-changes" rel="nofollow">http://docs.python.org/3.0/whatsnew/3.0.html#build-and-c-api...</a><p>In the scientific computing world C extensions are used everywhere and moving Python 2.x c extensions to Python 3 is a significant roadblock.
As a note, it's really sad to see these kinds of articles. I do perhaps 90% of my home programming in Common Lisp, a language which is around 30 years old, but still has an active development community. <i>Without modifications</i>, I can run code from 30 years ago on a modern computer and have it return correctly. I have no particular belief that this will be true for Python, Ruby, Perl 5, Perl 6, C++, and a variety of other popular languages developed <i>after</i> Common Lisp was popularized and standardized. So much effort wasted upgrading your language instead of solving your problems[1].<p>It's something to think about with your software choice: every line is a legacy line for someone else to understand and compile/interpret/run. Can they do it in the future? Do you <i>care</i>? If so, think hard and- I recommend- choose a language which has a formal standard with multiple implementations.<p>[1] Obviously innovation is useful. But reinventing wheels into the same design isn't. Obviously Haskell and other research-y languages will change. I'm talking about production languages for production environments or for other things persisting over the 5-20+ year spans such as science.
Some of them will never stop using Fortran, ever, until they die. My old boss was trained with Fortran, and made a moderately successful career in particle physics never needing to learn new tools. The ideas he needed expressed were short, he was good at explaining them, and it was never too big an effort to turn them into something that could run in PAW, ROOT, Python, VHDL, whatever was needed. He did the thinking, and expressed it in the language he knew best. He had postdocs, graduate students, and sometimes undergrads to do the leg work. Would he have had a better career if he'd spent time learning new languages rather than thinking about solving physics problems? I doubt it; and he probably wouldn't have had as much fun.
Forgive the snark, but are we all moving to Python 3 now? Every time /I/ try to use Python 3, I look for code samples and libraries written in 3, but they're all sitting around version 2.7. Documentation searches bring up 2.7 docs for most things I want to do.<p>Don't get me wrong, I have nothing against Python 3, and many of the changes seem fairly sensible, but I shouldn't have to fight against it to do something that works perfectly well with minimal effort in 2.7. I guess that makes me a curmudgeon, but I don't want to dick around with Python from a theoretical standpoint, or take a great deal of time exploring its features. Since I usually only use it for quick-and-dirty scripts, this is my ideal use case. I honestly don't care how much better iterators and GC are handled with it.
Whatever tool is best for the job. I'm still using Fortran in some areas of my research (molecular dynamics stuff), but then I use CoffeeScript to post-process simulation results. Throw in some C when I need a good balance between speed and rapid development, and Haskell when I'm just messing around ;)
I actually wonder, will startup developers ever move to Pyton 3? Or hobbyist programmers? Python 2.x is still widely used in the industry and many startups actually seem like they won't be able to make a radical change and move. What do you think of status of Python 3 in the industry?
I once held a position as a systems programming for a big data science research institute at a large state University. RHEL 5.x comes with Python 2.4 by default. Our Platform compute clusters ran RHEL. We would build Python 2.7.x from source and use that rather than the older 2.4. However, we never used Python 3, nor needed it. No one cared about it. It was not a topic of conversation even. Python 2 got the job done and lot's of research code was written in it, and still is.<p>I have nothing against Python 2 or 3. I'm just relaying my own experience. We used a lot of C++ and Java too. And the Java guys were fond of Groovy. I did mostly C++ and Python.
I highly doubt it. There are a lot of scientists still clinging dearly to FORTRAN90. Many scientists think in terms of the next grant/paper, not the long-term goal. This results in short-sighted software decisions, which are exacerbated by the fact that most scientists are (very poorly) self-taught coders.
For me the two issues are:<p>1) Sage, which I use, is a huge project incorporating lots of other scientific software and using loads of Cython. It simply takes time to migrate all the dependencies and then Sage itself to Python 3, and it's not really a priority for anyone.<p>2) It's not really something that anybody seems to focus on a lot. Scientists mainly worry about science, minor differences in the programming language used are generally of little concern. Migrating to a different version is therefore not something most of them would spend time on, unless forced to by external circumstances.
Something the author didn't mention is that a lot of science-related python code relies on third party libraries to support devices they use. SR Research's Eyelink device, for instance, is accessable through API's provided by SR themselves, which are provided in C and in a number of Py2.x flavors. They don't provide it in 3.x, and so the experiment cannot be written in 3.x either. The scientists have no control over this, because its not an open source project, it all relies on whether or not the company producing it wants to upgrade.
Libraries and legacy code are an issue, but if the Julia ( <a href="http://julialang.org/" rel="nofollow">http://julialang.org/</a> ) folks manage to deliver most of their promises, Julia might cover a lot of the data processing needs (and is faster than Python), for which people use Python + NumPy at the moment.<p>And the main reason some scientist migrated to Python is probably that Matlab is non-free, and the language of Matlab sucks. Julia might attract both Python users and future Matlab refugees.
As a scientist who teaches Python to other scientists in the summers, I wonder if what we instead need to do is just get a sufficient mass of <i>new</i> Python 3 programmers, and let them drag the rest over. Many fields long ago accepted that programming is a vital skill, but that's only recently been true in biology (if it even is true yet), so there's a lot more people who will be learning in the next few years, as compared to, for instance, astrophysics.
Hmm.. they sound a lot more eager than the networking world. Django, Twisted and Gevent are all still lacking Python 3 support. Saying that the biggest scientific packages only got support in 2010-2011 sounds like a pretty good track record to me!