On 4/20/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I'm afraid I disagree. PEP 302 actually has some tremendous advantages > over a pure objects-on-sys.path approach: > > * Strings can be put in any configuration file, and used in .pth files > > * Strings can be put in environment variables (like PYTHONPATH). > > * Strings can be printed out, with all their contents showing and nothing > hidden > > In short, strings are better for humans.
I think I like this. I wonder if there's a parallel with my preference for strings as paths instead of path objects... > There are only two things wrong with PEP 302 IMO, and neither is its "fault". > > The first is that the "classic" import machinery isn't on sys.meta_path, > and the 'imp' API isn't defined in terms of PEP 302. Those two things > can't change without introducing backward incompatibilities. So it's a perfect py3k project. > 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. > > PEP 302 is reasonably clear and concise, although there are occasional > loopholes. At least three people have re-implemented parts of it in pure > Python from the spec: Just van Rossum, Neal Norwitz, and myself (twice, in > my case). It is easy and elegant -- the only hard parts are when you have > to wedge all the "classic" imports in, or if you want to implement "format" > importers. > > So, my vote for Py3K is to move the classic import machinery to explicit > objects on sys.meta_path -- preferably one for each distinct rule, so that > it is possible to *remove* them if you don't want them. (For example, the > Chandler folks have made a big deal about not wanting general Windows > registry imports to apply; it would be nice if they could just delete an > object from sys.meta_path rather than having to build their own Python to > elide this.) +1 > I would also suggest that we ask Just if he can come up with some elegant > extension that would allow PEP 302 to support pluggable import *formats* as > well as locations. :) I guess you'll need to explain this particular problem a bit better... -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
