[Import-sig] Re: Long-awaited imputil comments

Gordon McMillan gmcm@hypernet.com
Wed, 16 Feb 2000 16:24:45 -0500


[Gordon]
> > If a freeze mechanism is analyzing source, then it needs 
> > source, but I don't think that's necessary. Then only other 
> > reason I can see for wanting source is if freeze is running with 
> > one magic number, but the frozen code will run with another, 
> > (to which I say "tough toenails, tootsie").

[Guido]
> Maybe my freezer wants to store the source as well as the code
> objects, so it can give decent tracebacks.
> 
> Which reminds me -- we need to introduce a standard API to retrieve
> the source for a module that's been imported (if it's available at
> all).  I can easily see how archives can be distributed containing
> both .pyc and .py files; the zip access module could easily find the
> .py file on request.

[Fredrik]
> Which reminds me...  it would be nice if an import handler
> can provide optional "find corresponding source" hooks for
> traceback.py and friends.
> 
> (among other things, this would allow pythonworks to use
> an archive file as the "workspace"...)

Hmm, wasn't there a reference earlier today to "You ain't 
gonna need it"?

Java doesn't do it.

You can already do it if you install source, then archive it, 
leaving the __file__ attribute alone - IDLE / Pythonwin will pop 
up the source.

Nobody sane is going to put code under active development in 
an archive.

A developer who wants run from an archive, yet see (but not 
alter) the source at a traceback can do as above (install 
source, then archive it).

Users who don't know and don't care can snip the traceback 
and send it to the developer, who can find the source.

Yeah, it can be supported, but Pythonworks is the only people 
who are going to use it, and the mad scientist can code it up 
in 10 minutes ;-). 

- Gordon