Are you expecting the same running interpreter to have both python 2 and 3 modules at the same time, with calls between the modules working?  You can easily keep things separate - python 2 executable is named python while python 3 is python3.  <a href="https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0397&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.python.org&#x2F;dev&#x2F;peps&#x2F;pep-0397&#x2F;</a><p>Sadly concurrent running in the same interpreter won&#x27;t work because Python 3 has different types for strings (unicode only) and a bytes type, while Python 2 has a str type (pretty much like bytes but can also be treated as a string) and a separate unicode type.  Python 2 had code that tried to do the right thing automagically with str, such as automatic promotion to unicode where it looks like you really meant a string and that is what is needed.  Automatic promotion can fail, be unexpected, is hard to test and numerous other issues.  That is why Python 3 was needed and why it needed to be incompatible.  To have Python 2 and 3 code interoperate in the same interpreter would require another layer of automatic promotion&#x2F;demotion and heuristics when data goes between the two.<p>C++ was explicitly defined to be a superset of C so it doesn&#x27;t have these kind of issues.  The analogous situation would be if C didn&#x27;t distinguish between long and pointer types, and C++ did.  You&#x27;d need rules for how to convert between the two worlds, trying to combine or disambiguate the types depending on which way types are going.  It would be a mess.