Deprecating reload() ???

[John Roth]

"David MacQuigg" <dmq at gain.com> wrote in message
news:8ok3505b3b3g22bk8ci6iagptqav2cfi6r at 4ax.com...
> 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.

I can certainly see wanting to do that in a debug session - or even
with an editor that's broken the way PythonWin is broken (it doesn't
reload the top level module when you say Run unless it's been updated,
so it never reloads the lower level modules even if they've been updated.)

However, I don't remember the last time I used the debugger,
it's been so long. When you use TDD to develop, you find that
the debugger becomes a (thankfully) long ago memory.

However, if you want to be able to replace a module in a
running program, I suspect you'd be much better off designing
your program to make it easy, rather than depending on the
system attempting to find all the references.

John Roth

>
> -- Dave
>