Deprecating reload() ???

[Carl Banks]

David MacQuigg wrote:
> 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.


What if one of your users does something like 'y = M1.x + 1'; then
what are you going to do?

It seems to me that your noble effort to make reload() completely
foolproof is ultimately in vain: there's just too many opportunities
for a module's variables to affect things far away.


-- 
CARL BANKS                      http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work." 
          -- Parody of Mr. T from a Robert Smigel Cartoon