[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