Re: [Jython-dev] poor man freezing and loading from other sources: proposals and ideas

[Samuele P. <pe...@in...>]

Hi.

[Finn]
> >> Maybe a different worded ImportError should be printed when
> >> sys.classLoader is set.
> >I can hear them too <wink>, once I imagined the following ?ugly? solution
> >(but no import * or dir) that technically means having the packageManager
> >existsPacakage return always true <wink>. Not a good default but as special
> >option ...
> 
> I suppose it would silence a lot of the valid complaints. It would make
> debugging a erroneous setup more difficult and it feels somewhat
> unpythonic: "Errors should never pass silently".
> 
> I can't think of a good way of enabling this right now, but as a special
> option it is worth remembering.
There is no good way <wink>, if I remember well my code and the rules it 
enforces it is a matter of ~5 (a bit more with changes to Options) lines in the 
right place. We can even still use the gathered information to selectively issue 
warnings:
" java package 'foo' forced, no dir or import * support, could even not
exist ;)"
But yes it should be a special option, in any case  people could then complain 
about import * and dir failing:

 "You cannot stop people from complaining, but you can influence what
they complain about." - Tim Peters

> 
> >> >To be honest this one  is the more complicated of the proposed changes,
> >> >here some concrete ideas:
> >> >
> >> >0. have a tool to "index" a jar in a way that supports dir (maybe the same
> >> >  as above under different options)
> >> 
> >> I believe that a .jar should only be scanned once. That means that if
> >> the scan result isn't cached we should reject un-indexed jars. Why don't
> >> you want to cache the scan result?
> >> 
> >> All in all this is my favorite.
> >Having the tool? caching things?
> 
> I don't mind caching the scan result, but if we decide that we shouldn't
> cache it, a tool that stores the scan result inside the jar is just as
> good IMO.
> 
> Rescanning for every session is wrong. I can't remember any complains
> about the initial scanning of jars but it is unacceptable to do it every
> time.
> ...
I will try all the possibilities and see the differences. (*)

> 
> >> >c. the overkill solution [maybe not that much but implies that we must 
live
> >> >   forever with the following CPython incompatibility (which is quite 
marginal):
> >> >      L=UserList.UserList()
> >> >      sys.path=L
> >> >   works in CPython but not in Jython, for c) we will have to even enforce 
this]
> >> >   add to builtin lists the possibility to have an observer (it costs
> >> >   the comparision between a ref and a null on every update method)
> >> >   that is notified for changes, so we can open, scan and close things
> >> >   on sys.path changes. Why every list? to make rare things work:
> >> >      L=['.','foodir']
> >> >      sys.path=L
> >> >      L.append('bazdir')
> >> >   When a list is assigned to sys.path its observer field is assigned,
> >> >   the field of the old one is reset...
> >> 
> >...
> >> 
> >> Or wrap the list 'L' above with an observable wrapper that intercepts
> >> __XXXitem__ calls. That would close the archive immeditatly but cause
> >> the value returned by 'sys.path' to be different from the value
> >> assigned. My favorite solution.
> >Ok for me but the example above that modifies sys.path trough L will not work 
(?)
> 
> ohh right. No it won't work. My bad.
Sorry, this is too much emotionally and with irony overloaded.
Do you mean you were aware? we both are.
In any case if it is ok for you to live with this problem, it is ok for me
too. But that's a point where we need a decision...
It is still your favorite? with some logic to deal with "off-line" changes
it should be fine up to the problem.

Otherwise there is the overkill solution or keeping them just open, which
maybe is not that bad.

<+
For the poor man freezing case we need a tool anyway  (*),
I think that a resource org/python/inf/frozen.list could be ok (?)
for storing the collected info.

regards.