Re: [Jython-dev] reloading...

[<bc...@wo...>]

On Sun, 31 Dec 2000 03:48:45 +0100, you wrote:

>I'm about to start working on some experimental support for reloading of
>java classes.
>The interface will be somehow different - as already discussed long time
>ago - to that for python modules.
>Now the required primitives are in place in the codebase, and the class name
>clash bug is fixed.
>
>    For the moment I imagine three levels/ways of support for reload
>These are illustrated in the form of some examples of usage (the interface
>is clearly not definitive):

This is just my initial thoughts.

>0)
>    import reload
>    reload.createLoadSet("XLS",['d:/exp','d:/exp2'])

Does this automaticly bind the XLS name in locals()? I would rather see
some kind of explicit binding:

   XLS = reload.createLoadSet("XLS",['d:/exp','d:/exp2'])

>    import XLS.com.xyz.utils.BlobReader
>    from XLS.com.xyz.utils import Blob
>
>    print XLS.com.xyz.utils.BlobWriter.getVersion()
>
>    reload(XLS)
>
>   # Blob still refers to the old/same version

Ofcourse it does. Users will be surprised at this, but that is
unavoidable. IMO it is more interesting what happen here:

    from XLS.com.xyz import utils
    b1 = utils.Blob()
    reload(XLS)
    b2 = utils.Blob() # would this Blob also be the old version?

If this will get the new version of Blob, I don't mind the explicit
reference to the XLS loadset in imports.

>    print XLS.com.xyz.utils.BlobWriter.getVersion() # refers to new version
>    # XLS.com.xyz.utils.BlobReader
>1)
>    import reload
>    xls =
>reload.createLoadSet('<anononymous>',['d:/exp','d:/exp2'],topExport=['com.xy
>z'])
>    # works only if com.xyz is not an existing package under the hierarchy
>    # controlled by the system package manager
>
>    print com.xyz.utils.BlobWriter.getVersion() # this works without
>prefixing with the load-set
>
>    xls.reload()

Similarly; Is it only com.xyz.__dict__ that is reloaded or is it also
and automaticly a locally bound utils package?

>   print com.xyz.utils.BlobWriter.getVersion() # new version
>2) # same as 1, but should work for packages that are also under control of
>the system package manager
>    # with that is not meant that we have reloading from classpath or
>sys.path
>    # but that package content could be splitted between a fixed part coming
>from classpath, sys.path
>    # and a reloadable one coming from a separated set of directories
>
>Clearly a possibility is to have all them together.
>0) I feel is the "more pythonic" being a load set some kind of package that
>can be reloaded as a whole.

That is my feeling too.

>It also the less confusing for the user.
>1) This has the big advantage that the code for the development/test phase
>and the final code contain the same imports.
>  Can be a bit more confusing.
>*)  Clearly the idea is that the reload.createLoadSet are idempotent. To
>have the "same" call in many modules
>  should report no error... Clearly at least one call should be issued
>before trying to import things from
>  the load-set.
>2) Is more complicated to implement and can be very confusing. I do not know
>wheter it's worth the effort.

IMO, it isn't worth it for the first effort.

>I think 0+1 make sense.

I would prefer just the 0 solution initially. As we (by that I mean I)
gain more experience with reloading, we can always add more ways.

regards,
finn