[Python-Dev] New Import Hooks PEP, a first draft (and req. for PEP #)

[Thomas Heller]

Just van Rossum <just@letterror.com> writes:

> Thomas Heller wrote:
> 
> > Looks ok to me, although I would prefer to write
> > 
> >         path = os.sep.join(__name__.split(".") + ["wininst.exe"])
> > or
> >         path = os.path.join(*__name__.split(".") + ["wininst.exe"])
> 
> Much better. I think I'd prefer the first, mostly because os.path.join()
> might do more magic than needed.

Me too. Also because I wasn't sure first if I had to write
         path = os.path.join(*l1 + l2)
or
         path = os.path.join(*(l1 + l2))

> 
> I think it's time to pin down the next extensions to the importer
> protocol. How about the next speclet:
> 
>     bool = loader.is_package(fullname)
>     code = loader.get_code(fullname)
>     str = loader.get_source(fullname)
> 
> (is_package and get_code are needed for modulefinder-like tools,
> get_source is needed for linecache-like tools.)

I like this much better than Jim's proposal, although I cannot think
too deep currently about this.

> 
> All three should raise ImportError if the module isn't available.
> get_code and get_source should return None if there's no code or source
> associated with the module, respectively. "No code" means it's a builtin
> module or an extension. "No source" means just that (eg. for zipimport
> it would mean "I've only got a .pyc or .pyo file for you").
> 
> If the importer does support get_source(), yet doesn't have a code
> object readily available, get_code() should compile the source by itself
> and return the code. This is to make life easier for the caller: if it
> only needs the code object it shouldn't need to also check get_source()
> and deal with that.
> 
> They should be optional, yet strongly recommended for general purpose
> hooks. There's no need to support them for hooks that are specific to a
> deliverable app; for example zipimport should have them, but if Thomas
> writes a dedicated hook for the apps built by py2exe, he should be free
> to leave them out.
> 
> Btw. would it be better if mod.__importer__ was named mod.__loader__?

Yes.

> This is closer to the truth, yet I fear that __loader__ is too generic.

Before I can give better comments, I have to read the PEP it seems.

Thomas