Deprecating reload() ???

[David MacQuigg]

On Mon, 15 Mar 2004 05:49:58 -0600, Skip Montanaro <skip at pobox.com>
wrote:

>    Dave> Maybe we could somehow switch off the generation of shared objects
>    Dave> for modules in a 'debug' mode.
>
>You'd have to disable the integer free list.  There's also code in
>tupleobject.c to recognize and share the empty tuple.  String interning
>could be disabled as well.  Everybody's ignored the gorilla in the room:
>
>    >>> sys.getrefcount(None)
>    1559

Implementation detail.  ( half wink )

>In general, I don't think that disabling immutable object sharing would be
>worth the effort.  Consider the meaning of module level integers.  In my
>experience they are generally constants and are infrequently changed once
>set.  Probably the only thing worth tracking down during a super reload
>would be function, class and method definitions.

If you reload a module M1, and it has an attribute M1.x, which was
changed from '1' to '2', we want to change also any references that
may have been created with statements like 'x = M1.x', or 'from M1
import *'  If we don't do this, reload() will continue to baffle and
frustrate new users.  Typically, they think they have just one
variable 'x'

It's interesting to see how Ruby handles this problem.
http://userlinux.com/cgi-bin/wiki.pl?RubyPython  I'm no expert on
Ruby, but it is my understanding that there *are* no types which are
implicitly immutable (no need for tuples vs lists, etc.).  If you
*want* to make an object (any object) immutable, you do that
explicitly with a freeze() function.

I'm having trouble understanding the benefit of using shared objects
for simple numbers and strings.  Maybe you can save a significant
amount of memory by having all the *system* modules share a common
'None' object, but when a user explicitly says 'M1.x = None', surely
we can afford a few bytes to provide a special None for that
reference.  The benefit is that when you change None to 'something' by
editing and reloading M1, all references that were created via a
reference to M1.x will change automatically.

We should at least have a special 'debug' mode in which the hidden
sharing of objects is disabled for selected modules. You can always
explicitly share an object by simply referencing it, rather than
typing in a fresh copy.

x = "Here is a long string I want to share."
y = x
z = "Here is a long string I want to share."

In any mode, x and y will be the same object.  In debug mode, we
allocate a little extra memory to make z a separate object from x, as
the user apparently intended.

If we do the updates for just certain types of objects, we will have a
non-intuitive set of rules that will be difficult for users to
understand.  I would like to make things really simple and say:
"""
If you have a direct reference to an object in a reloaded module, that
reference will be updated.  If the reference is created by some other
process (e.g. copying a string, or instantiation of a new object based
on a class in the reloaded module) then that reference will not be
updated.  Only references to objects from the old module are updated.
The old objects are then garbage collected.
"""

We may have to pay a price in implementation cost and a little extra
storage to make things simple for the user.

-- Dave