Deprecating reload() ???

[Peter Hansen]

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 think many applications would be inherently broken if a programmer 
thought a simple "reload" of the style you envision would work without 
serious but possibly quite subtle side effects.

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

-Peter