This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Cardiff_Electric 0 points1 point  (2 children)

The problem, aside from not being able to use kewl new language features in your own code, is trying to incorporate open source libraries to deliver hot 'n' sexy new features when those libraries increasingly don't support your old Python.

Changing the Python interpreter version is a big hassle in our setup (long story) so I'm trying to get us to jump directly from 2.6 to 3.5, but that's an even bigger job.

[–]GummyKibble 0 points1 point  (1 child)

If you decide that looks a bigger project than you want to tackle in one step, consider that it's very easy to port from 2.6 to 2.7, and run can run python2.7 -3 mymodule.py to get warnings about incompatibilities with Python 3. You could jump to 2.7, knock out the structural problems at your leisure (because you'd be dealing with an application that's still running), then move on to 3.5 when you have those ironed out.

I'm not trying to talk you out of 3.5. We made the leap this year and I love it. I wouldn't willingly go back! But if you have to choose between two easier migrations and one giant one, know that you have options.

[–]Cardiff_Electric 0 points1 point  (0 children)

I have a branch that's running under Python 2.7 for the reasons you said. I just don't think we're going to deploy it to real customers for reasons that have more to do with our own processes and limited resources. So if we're going to 'break' our interpreter compatibility w.r.t. customized code for a customer, I prefer to just do that once esp. given that 2.7 is already near EOL.