<br><br><div><span class="gmail_quote">On 7/20/06, <b class="gmail_sendername">Nick Coghlan</b> <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For code objects, their construction is already commonly written as<br>"compile(source)".</blockquote><div><br>Right, but some people like to construct directly from bytecode. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
For type objects, the constructor doesn't let you do anything you can't<br>already do with a class statement. It doesn't need securing.</blockquote><div><br>I figured as much, but when I was making the list I was not sure and didn't want to stop my writing momentum to check.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For rewriting import.c in Python, the PEP 302 compliant import system API in<br>
pkgutil would be a good starting point.</blockquote><div><br>Yep. Plan on looking at all of the various modules in the stdlib that assist with importing, package PEP (I think there is one), and PEP 302.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Your doc also asks about the imp.get_suffixes() list, and wonder where to set<br>it from Python.<br><br>As far as I am aware, you can't. get_suffixes() is built from<br>_PyImport_FileTab, which is a C array. A switch statement is used to get from
<br>the file table entries to the appropriate handler functions.</blockquote><div><br>Ah, OK. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Quoting from the suggestions I put to the Py3k list:<br><br>Use smarter data structures<br>---------------------------<br>Currently, the individual handlers to load a fully identified module are<br>exposed to Python code in a way that reflects the C-style data structures used
<br>in the current implementation.<br><br>Simply switching to more powerful data structures for the file type handlers<br>(i.e. use a PyTuple for filedescr values, a PyList for _PyImport_FileTab, and<br>a PyDict instead of a switch statement to go from filedescr values to module
<br>loading/initialisation functions) and manipulating them all as normal Python<br>objects could make the code in import.c much easier to follow.</blockquote><div><br>Yep. I just kind of glanced at the rest of your suggestions, Nick, since I assumed a lot of it would change (or could be changed) if import was redone in as much Python as possible.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Extensible file type handling<br>-----------------------------<br>If the file type handlers are stored in normal Python data structures as
<br>described above, it becomes feasible to make the import system extensible to<br>different file types as well as to different file locations.</blockquote><div><br>Yep. Although I am more interested in restricting than broadening the file types.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This could be handled on a per-package basis, e.g. via a __file_types__<br>special attribute in packages.
</blockquote><div><br>Maybe. I don't want to get into introducing new abilities to start, though.<br></div><br><br>-Brett</div>