[Python-Dev] how important is setting co_filename for a module being imported to what file is set to? (original) (raw)

Brett Cannon brett at python.org
Mon Aug 31 18:34:41 CEST 2009

On Mon, Aug 31, 2009 at 06:13, Nick Coghlan<ncoghlan at gmail.com> wrote:

Brett Cannon wrote:

You can use the C implementation of io, io, which has a full buffering implementation. Of course, that also makes it a better harder for other implementations which may wish to use importlib because the io library would have to be completely implemented...

True. I guess it's a question of whether making importlib easier to maintain and as minimally reliant on C-specific modules is more/less important than trying to bootstrap it in for CPython for import at some point. I'd suggest preferring io, but falling back to the Python io module if the accelerated version doesn't exist. You should get the best of both worlds that way (no bootstrap issues in CPython and other implementations with an io module, but a still functional importlib in other implementations).

Well, all important code is in importlib._bootstrap which lacks a single import statement; all dependent modules are injected externally in importlib.init. That allows for the possibility of C code to import importlib/_bootstrap.py along with the buit-in modules required, and then inject those built-in modules into importlib's global namespace. This is why I have functions in there that are duplications of things found elsewhere.

That means that while I have named the module _io and I use _io.FileIO, you could also easily inject io with the name _io and have everything just work if you were trying to bootstrap. The deal is that if I want to keep up the bootstrap goal I need to continue to restrict myself to either built-in modules or thing I know I can choose to expose later in built-in modules. This is why when Guido suggested os.open I said I will have to see how it is implemented because if it doesn't come from posix or is easy to duplicate I won't be able to use it.

-Brett

More information about the Python-Dev mailing list