Deprecating reload() ???
Carl Banks
imbosol at aerojockey.invalid
Mon Mar 15 23:43:01 EST 2004
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
More information about the Python-list
mailing list