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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
