> >I have checked the code of your 2nd patch (but yet not tried it).
> >The patch is neat, but here are some comments:
> >> The magic string -> SyspathArchive works on all paths of this form, but
> >> it will cause the archive to be opened each such a string is found on
> >> sys.path. Hardly a problem I think.
> >I don't know if that's a problem or not, but in case a central
> >cache with a (incredible under java) simple ref count logic can do the job.
> >I propose ref counting because weak-refs work only under Java2.
> We can add it later if it turns out to be a problem.
> >The logic for detecting a jar!relpath entry seems a bit weak, if the user
> >have paths around containing a !. Insane, of course, but ...
> It'll happen at some point. I'll add an additional test on whether the
> full string is a directory and skip the new zip logic if it is.
> >Maybe SysArchives should have an archive_close method (in case), closing
> >the zip or playing well with the central cache.
> Yeah but the semantic then depends on the implementation. If some code
> in package calls archive_close() on the SyspathArchive in its __path__
> should further imports from the SyspathArchive on sys.path still
Yes with a re-open logic, or no raising a specific exception:
encountered closed SyspathArchive,
The second option seems more meaningful to me.
A special case is sys.path and java class loading:
there if you remove an archive from sys.path after you have loaded
some classes, maybe you can get an error later, because the loading
of some referenced classes can fail.
It depends on when resolve is called.
I don't remember the details.
> >The final point: imp has always been a bit messy (I always wanted to
> >polish it a bit ..), and now loadFromZipFile adds another amount of code
> >duplication wrt loadFromPath ...
> >so I would prefer things factored in another way...
> >in case I can do that.
> I agree, but lets do the refactoring after 2.1 final and before 2.2a1.