Not wishing to put words in the mouths of the creators, but there are a few reasons why one might target 2.7 rather than 3.x:
1. 2.7 is a stable target. There will be no further features added to the 2.x series.
2. 2.7 is a known target. Other experiments like PyPy have already tried many paths to improve 2.7, so what doesn't work is reasonably well known.
3. 2.7 is a widely deployed target. This is less important from an "adoption" point of view, more so that there is a lot of software written that targets 2.x, meaning there's more software to test with.
4. Finally, I suspect much of Dropbox's codebase is 2.7[1], and since this is an effort to improve things for Dropbox, it makes sense to spend the initial efforts there :)
[1] checking the version of Python bundled with the Dropbox client confirms that it, at least, is 2.7
1 is a big item. It is not fun playing catchup. CPython actually suspended any "language change" from 2009 to 2011 so that alternative implementations can catch up.
On the other hand, starting behind just means you have even more catching up to do. This happened in my personal VM project with ruby. I targeted ruby 1.8.7 when all these things held true for it, but by the time I got to it running most of the rubyspec language specs, 1.8.7 was basically obsolete.
1. 2.7 is a stable target. There will be no further features added to the 2.x series.
2. 2.7 is a known target. Other experiments like PyPy have already tried many paths to improve 2.7, so what doesn't work is reasonably well known.
3. 2.7 is a widely deployed target. This is less important from an "adoption" point of view, more so that there is a lot of software written that targets 2.x, meaning there's more software to test with.
4. Finally, I suspect much of Dropbox's codebase is 2.7[1], and since this is an effort to improve things for Dropbox, it makes sense to spend the initial efforts there :)
[1] checking the version of Python bundled with the Dropbox client confirms that it, at least, is 2.7