On Sun, 31 Dec 2000 03:48:45 +0100, you wrote:
>I'm about to start working on some experimental support for reloading of
>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.
> import reload
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()
> # 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()
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
> import reload
> xls =
> # 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
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
> # 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.