[Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

[Brett Cannon]

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