> it is practically always trivial for a Python2 programmer to write new code in Python3.
Until you need to use some library that doesn't support python3. I think I've made the transition from python3 to python2 more than I have the other way around.
I've been writing forward compatible py2 code for years using the __future__ imports to ensure proper semantics are preserved. When all my external dependencies have py3 support it becomes a breeze to upgrade using 2to3 and the rare occasional manual fixup.
Not sure why this was downvoted. I'm currently still in Python2 and looking to upgrade to Python3. Having solid automated tests is vital for us to do it confidently.
But do you have tests for your tests? Assuming tests are written in Python2, gotta make sure they don't start testing the wrong things when you upgrade them...
The way I think of it, the code tests the tests. It's the the same way keys and locks verify each other.
Is there some sort of failure mode you're thinking of where I'd still see all the tests run but the test framework would give false success for something?
That argument is becoming a good way to tell who hasn't actually tried Python 3 lately, or is using out of date libraries.
More and more of the bigger libraries are ported already, and a lot of the others have been replaced by newer libraries that work with Python 3. If the library you're trying to use doesn't support Python 3, it's probably a good indication most people have moved on to something better...
Or until you trip over the API differences between str and bytes in Python 3 that do not exist in Python 2 (because str == bytes in Python 2). Chiefly, printf-style formatting...
>>> b"%u" % 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for %: 'bytes' and 'int'
Until you need to use some library that doesn't support python3. I think I've made the transition from python3 to python2 more than I have the other way around.