jython-dev

[Jython-dev] reloading...

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

Hi.

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):
0)
    import reload
    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

    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()

   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.
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.

I think 1+2 make sense.

Comments are welcome.

regards, Samuele Pedroni.

[Jython-dev] reloading... : errata

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

Hi. I wrote that too quickly so here are some errata:

Very little thing: clearly a reload support module for java classes cannot
be called reload or we
get a very bad name clash with the reload builtin: something like jreload on
the model of jarray ... will
do the job.

[me writing too quickly]
> I think 1+2 make sense.
Truly I meant "0+1 make sense".

regards, Samuele Pedroni.

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