On Mon, Aug 31, 2009 at 06:13, Nick Coghlan<ncogh...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
