[Python-ideas] A python bridge between versions

ian o ian.team.python at gmail.com
Fri Feb 28 00:26:02 CET 2014


 

The most quoted reason for staying with python 2 is that some required 
library is not available to support python 3. All it takes is one legacy 
library module in python 2 to keep an entire project in python 2.

Many significant projects (e.g web2py) continue in python 2 for this 
reason. Even projects that produce code that can work under either python 2 
or python 3, are themselves trapped into only using python 2 features.


 This is really holding back python!


 You cannot just import python2 code into the python 3 interpreter as it is 
not compatible.

 But could this be solved by a new approach which is to treat python 2 as 
another language and not directly import the code but handle python 2 code 
with an an extension module, which acts as bridge between versions.


 I mean, python three program can access C/C++ code (which is not python3), 
why can't the access python 2 code by treating it like C/C++?


 This would require an extension C module called from python 3. How to do 
this is well known. This extension C module would itself call the required 
module library(s) from python2. Calling python from C is also a well known 
technique.


 Ptyhon can call C. C can call python. So python3 call C which calls 
python2.


 So in python3 

imput <python2-module> # this usually won't work because of language changes


 becomes


 import python2

<python2-module> = python2.import('<python2-module>')


 
 The resultant imported module would appear as a c++ extension to python3 
and in effect be a wrapper for the python2 module using the python2 
extension to execute the code 

This would mean programs using python2 imports have the overhead of both 
interpreters running in memory and calls across the python3/python2 
boundary are 'wrapped' as c++ calls that then activate the required code 
within python 2. In reality quite a small overhead on modern computers.


 python2.sys.path


 (within the 'python2' module)


 or similar would be needed for the separate import space running inside 
the python2 boundary.


 Callbacks back across the python3/python2 boundary back into python3 are a 
further complication but several possible solutions exist to deliver this. 
Not many library modules require callback functions to the library module 
itself so this not the central issue. There is some work for the person 
coding the python 3 app in terms of a different syntax for legacy module 
imports and potentially setting python 2 environment values (like 
python2.sys.path), but not a lot and the python3 is the new program being 
worked on as opposed to the legacy library which can remain untouched.


 I think this type of approach could change the recommendation on 'python 2 
or python 3' to a simple 'get the latest available to you and here is how 
to use legacy libraries if you have the need'.


 Thoughts or criticisms?

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140227/c83a3fa4/attachment-0001.html>


More information about the Python-ideas mailing list