[Distutils] Re: new import mechanism and a "small" distribution

[Greg Stein]

On Mon, 1 Feb 1999, Just van Rossum wrote:
> Greg Stein wrote:
> >get_code() is *NOT* a public method. It is for subclasses to override.
> 
> Oh, ok. But that makes it very specific to your implementation. I'd like to
> see a much more general idea. I'm sure that it's there in your code but it
> is not very clear...

My post was only about implementation, as an expression of an implicit
design :-)

And yes, it appears that the doc could be clearer.

> >The "public method" is the _import_hook method, but it isn't really
> >public, as it gets installed into the import hook. However, it wouldn't
> >be hard to add "__call__ = _import_hook" to the Importer class. That
> >would provide the appropriate callable interface.
> 
> I see, that makes sense. Then the idea could boil down to something like this:
> 
> Each element of sys.path is either of these:
> - a string, in which case the "classic" importer will do the work.
> - a callable object, which must have the same interface (signature) as the
> current __import__ hook.
> 
> (that's basically where you started, right?)

Exactly.

And within that design, my implementation also favors a single-step import
mechanism rather than the find/load style that has characterized previous
import mechanisms (imp, ihooks, Mark/Jack's email, etc). 

The import design is also compatible with existing code. Only when
somebody begins to insert callable objects will old apps potentially
break. IMO, they can choose to not use callable objects and leave their
app alone, or use callables and fix their app to compensate.


Mainly, I'm just hoping that my code is useful to demonstrate viability of
the approach that I'm recommending. "Code talks" :-)  I've certainly found
the Importer class to be a clearer way to write custom import hooks than
anything else that I've seen (try writing a subclass of the ihooks
classes, and you'll see what I mean).

Cheers,
-g

--
Greg Stein, http://www.lyra.org/