[Python-3000] Changing the import machinery

[Ian Bicking]

Phillip J. Eby wrote:
> The second is that PEP 302 only covers "location" importers, not "format" 
> importers.  That is, if you want to do something like make Kid or Cheetah 
> templates importable, you have to replace things with new machinery.  This 
> is a more important problem to solve, IMO, than coming up with yet another 
> set of semantics for the things that *are* covered by PEP 302.

I think the specific examples (Kid and Cheetah) are places where import 
machinery is used when it shouldn't be.  Or at least, when it would be 
better to use more path-based machinery.

(Brief explanation: Kid and Cheetah are template languages that compile 
to importable Python code; they have import hooks so you can import .kid 
and .tmpl files as though they were Python files)

Realistic use cases for templates often involve fairly complicated sets 
of overlapping hierarchies, searched depth-first.  I guess not entirely 
unlike some complicated import machinery, except that the rules are 
really limited to templates and I don't see a reason to mix in templates.

Maybe you wouldn't have to mix it all together... if sys.path, 
sys.meta_path, and sys.modules (and maybe some other stuff I don't know 
of) were really instance variables of some ModuleEnvironment object, and 
you could instantiate a new ModuleEnvironment that was specific to 
templates.  Probably to be filed under crazy ideas.


-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org