Deprecating reload() ???

[David MacQuigg]

On Fri, 12 Mar 2004 13:34:36 -0500, Peter Hansen <peter at engcorp.com>
wrote:

>David MacQuigg wrote:
>
>> On Fri, 12 Mar 2004 08:45:24 -0500, Peter Hansen <peter at engcorp.com>
>> wrote:
>>> Reload is not broken, and certainly shouldn't be deprecated at least 
>>> until there's a better solution that won't suffer from reload's one 
>>> problem, IMHO, which is that it surprises some people by its behaviour.
>> 
>> It's worse than just a surprise.  It's a serious problem when what you
>> need to do is what most people are expecting -- replace every
>> reference to objects in the old module with references to the new
>> objects.  The problem becomes a near impossibility when those
>> references are scattered throughout a multi-module program.
>
> I don't consider this a problem with reload, I consider it a design 
> defect.  If there's a need for such a thing, it should be designed in to 
> the application, and certainly one would remove the "scattering" of 
> objects such as these which are about to be replaced en masse.

I agree, most programs should not have 'reload()' designed in, and
those that do, should be well aware of its limitations.  I'm concerned
more about interactive use, specifically of programs which cannot be
conveniently restarted from the beginning.  I guess I'm spoiled by HP
BASIC, where you can change the program statements while the program
is running! (half wink)

>>>I think that when you consider Python's namespace mechanism, you can't 
>>>avoid the possibility of situations like the ones reload can now lead to.
>> 
>> I don't understand.  My assumption is you would normally update all
>> references to the selected objects in all namespaces.
>
>I guess we're coming at this from different viewpoints.  My comments 
>above should probably explain why I said that.  Basically, it seems to 
>me very unlikely there are good use cases for wanting to update the 
>classes behind the backs of objects regardless of where references to 
>them are bound.  I'm open to suggestions though.

Objects derived from classes are a different, and probably unsolvable
problem.  Attempting to update those would be like trying to put the
program in the state it would have been, had the module changes been
done some time in the past.  We would have to remember the values at
the time the object was created of all variables that went into the
__init__ call.  Classes don't have this problem, and they should be
updatable.

Here is a use-case for classes. I've got hundreds of variables in a
huge hierarchy of "statefiles".  In my program, that hierarchy is
handled as a hierarchy of classes.  If I want to access a particular
variable, I say something like:
wavescan.window1.plot2.xaxis.label.font.size = 12
These classes have no methods, just names and values and other
classes.

If I reload a module that changes some of those variables, I would
like to not have to hunt down every reference in the running program
and change it manually.

-- Dave