Deprecating reload() ???

[David MacQuigg]

On Mon, 15 Mar 2004 11:33:04 -0600, Jeff Epler <jepler at unpythonic.net>
wrote:

>This is guaranteed to work:
>    x = None
>    y = None
>    assert x is y
>by the following text in the language manual:
>        None
>            This type has a single value. There is a single object with
>            this value. This object is accessed through the built-in
>            name None.  It is used to signify the absence of a value in
>            many situations, e.g., it is returned from functions that
>            don't explicitly return anything. Its truth value is false.
>There are reams of code that rely on the object identity of None, so a
>special debug mode where "x = <some literal>" makes x refer to something
>that has a refcount of 1 will break code.
>
>The 'is' guarantee applies to at least these built-in values:
>    None Ellipsis NotImplemented True False

This certainly complicates things.  I *wish* they had not made this
"single object" statement.  Why should how things are stored
internally matter to the user?  We could have just as easily worked
with x == y, but now, as you say, it may be too late.

The same problem occurs with strings (some strings at least):
>>> x = 'abcdefghighklmnop'
>>> y = 'abcdefghighklmnop'
>>> x is y
True
>>> x = 'abc xyz'
>>> y = 'abc xyz'
>>> x is y
False

Since there is no simple way for the user to distinguish these cases,
it looks like we might break some code if the storage of equal objects
changes.  The change would have to be for "debug" mode only, and for
only the modules the user specifically imports in debug mode.  We
would need a big, bold warning that you should not use 'is'
comparisons in cases like the above, at least for any objects from
modules that are imported in debug mode.

>The only problem I can see with reload() is that it doesn't do what you
>want.  But on the other hand, what reload() does is perfectly well
>defined, and at least the avenues I've seen explored for "enhancing" it
>look, well, like train wreck.

It's worse than just a misunderstanding.  It's a serious limitation on
what we can do with editing a running program.  I don't agree that
what it does now is well defined (at least not in the documentation).
The discussion in Learning Python is totally misleading.  We should at
least update the description of the reload function in the Python
Library Reference.  See the thread "Reload Confusion" for some
suggested text.

-- Dave