I am at the point with my security work that I need to consider how I am going to restrict importing modules.  My current plan is to basically implement phase 2 of PEP 302 and control imports through what importer objects are provided.  This work should lead to a meta_path importer for built-ins and then path_hooks importers for .py, .pyc, and extension modules.
<br><br>But it has been suggested here that the import machinery be rewritten in Python.&nbsp; Now I have never touched the import code since it has always had the reputation of being less than friendly to work with.&nbsp; I am asking for opinions from people who have worked with the import machinery before if it is so bad that it is worth trying to re-implement the import semantics in pure Python or if in the name of time to just work with the C code.&nbsp; Basically I will end up breaking up built-in, .py, .pyc, and extension modules into individual importers and then have a chaining class to act as a combined .pyc/.py combination importer (this will also make writing out to .pyc files an optional step of the .py import).
<br><br>Any opinions would be greatly appreciated on this.&nbsp; I need to get back to my supervisor by the end of the day Friday with a decision as to whether I think it is worth the rewrite.&nbsp; If you are interested in helping with the Python rewrite (or in general if the work is done with the C code), please let me know since if enough people want to help with the Python rewrite it might help wash out the extra time needed to make it work.
<br><br>-Brett<br>