Intersection of built-in modules between CPython, Jython and IronPython
In the last couple of years or so Python has moved to the point where it has several strong and widely used implementations. The major ones, in terms of usage, are CPython, IronPython and Jython.
(A full list of Python implementations is difficult because it really depends by what you mean by "Python". PyPy definitely counts of course, but is Stackless a separate implementation and what about PyMite, Shedskin, Cython, cl-python, Boo, CrossTwine, HotPy and many other projects that are partial or partially complete implementations of Python?)
This changes the development of core-Python (the C implementation known as CPython) slightly. As well as being the most widely used implementation CPython also serves as the reference implementation for the others.
Brett Cannon is one of the more prolific of the rag-tag bunch of developers comprising the core development team. One of his tasks has been to fully implement the Python import machinery in pure Python: importlib. importlib is already part of Python 3.1, and what will become Python 2.7, providing an import_module function.
The intention is for importlib to become the default implementation of import for Python. By being written in Python this should make it easier for alternative implementations to use - so long as they have the requisite dependencies. In this blog entries Brett looks at which of the dependencies are already available in IronPython and Jython.
(A full list of Python implementations is difficult because it really depends by what you mean by "Python". PyPy definitely counts of course, but is Stackless a separate implementation and what about PyMite, Shedskin, Cython, cl-python, Boo, CrossTwine, HotPy and many other projects that are partial or partially complete implementations of Python?)
This changes the development of core-Python (the C implementation known as CPython) slightly. As well as being the most widely used implementation CPython also serves as the reference implementation for the others.
Brett Cannon is one of the more prolific of the rag-tag bunch of developers comprising the core development team. One of his tasks has been to fully implement the Python import machinery in pure Python: importlib. importlib is already part of Python 3.1, and what will become Python 2.7, providing an import_module function.
The intention is for importlib to become the default implementation of import for Python. By being written in Python this should make it easier for alternative implementations to use - so long as they have the requisite dependencies. In this blog entries Brett looks at which of the dependencies are already available in IronPython and Jython.
But using importlib as import imposes a bootstrapping problem. How do you import, well, import? First off, you need to find the source code, compile it into a code object, and create a module object using that code object. That part is actually easy as you can simply look for the file on sys.path since you know what you are looking for, you can compile the source using the built-in compile() function, and then you finally create a module and initialize it with exec(). This is essentially what importlib does at a rudimentary level.
But import obviously goes beyond the rudimentary. There is bytecode to read and write, packages to deal with, warnings to raise, etc. And all of that requires code from some module in the standard library. But if you are trying to bootstrap in import w/o having a full-featured import, what do you do? You rely on built-in modules is what you do.
By using built-in modules you could have the VM inject any built-in module into the created importlib module and have it begin using it. Because of this I was curious as to what built-in modules CPython 3.1, Jython 2.5, and IronPython 2.6b2 had in common.
Comments
Post a Comment