Deprecating reload() ???

[David MacQuigg]

On Fri, 12 Mar 2004 08:45:24 -0500, Peter Hansen <peter at engcorp.com>
wrote:

>David MacQuigg wrote:
>
>> I know this is the *intended* behavior of reload(), but it has always
>> seemed to me like a bug.  Why would you *ever* want to keep pieces of
>> an old module when that module is reloaded?
>
>If you wanted a dynamic module, where changes would be picked up by the 
>application from time to time, but didn't want to terminate existing 
>instances of the old version.  There's nothing wrong with the idea that 
>both old and new versions of something could exist in memory, at least 
>for a while until the old ones are finished whatever they are doing.

OK, I agree this is a valid mode of operation.

>Basically, envision an application update mechanism for long-running 
>applications, and its special needs.

I think a good example might be some objects that need to retain the
state they had before the reload.

>> Seems to me we should *fix* reload, not deprecate it.
>
>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.

For the *exceptional* case where we want to pick and chose which
objects to update, seems like the best solution would be to add some
options to the reload function.  

def reload(<module>, objects = '*'):

The default second argument '*' updates all references.  '?' prompts
for each object.  A list of objects updates references to just those
objects automatically.  'None' would replicate the current behavior,
updating only the name of the module itself.

The '?' mode would normally ask one question for each object in the
module to be reloaded, and then update all references to the selected
objects.  We could even have a '??' mode that would prompt for each
*reference* to each object.  

In a typical debug session, there is only one object that you have
updated, so I think there would seldom be a need to enter more than
one name as the second argument.

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

-- Dave