[Python-3000] Changing the import machinery
Ian Bicking
ianb at colorstudy.com
Fri Apr 21 18:37:27 CEST 2006
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
More information about the Python-3000
mailing list