ian o, 01.03.2014 04:09:
We have 3 teams working server systems currently with python as the implementation model. All work is currently in python 2.x and with a solution to this the work could immediately move to 3.x.
You are mixing things up here. If you are developing application code, you don't really have a problem. Either you stay with 2.x or you switch to 3.x. You may even decide to stay in Py2 with some of your applications and migrate the others. Or migrate one after the other, over months or years. You really don't have to break your running systems, and definitely not all of them at once. It's entirely your choice, and doing the switch (if you want to) really isn't all that hard. Nick pointed you to a couple of resources that can help you in the progress. Many, many others have done it before, and have found that breaking all bridges after you have passed over them is a perfectly reasonable and efficient way to migrate, *specifically* for application code. The real problem, and that's what Nick was referring to, is writing and maintaining libraries that others depend on, because these others may use Python 2.x (and may not even want to switch to Py3), or they may use Python 3.x (and do not care about Python 2.x). But the library authors do not control the application code. Therefore, to cater for both user groups, library maintainers currently have to write code that works on both platforms, which is annoying and time consuming. Since you seem to be interested in migrating your application code in order to take advantage of Python 3, my advice is to (ta-da!) start migrating your code. And when that's done, stop looking back. Any "solution" that involves running a mix of Py2 and Py3 inside of one application is just screaming for endless trouble. Don't forget that "temporary solutions" tend to be the most durable in practice. Stefan