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. But it has been suggested here that the import machinery be rewritten in Python. Now I have never touched the import code since it has always had the reputation of being less than friendly to work with. 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. 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). Any opinions would be greatly appreciated on this. 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. 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. -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060927/60f301e2/attachment.htm
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4