Deprecating reload() ???

[Skip Montanaro]

    >> 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.

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

Like I said, I think that sort of change will be relatively rare.  Just tell
your users, "don't do that".

    Dave> I'm having trouble understanding the benefit of using shared
    Dave> objects for simple numbers and strings.  

Can you say "space and time savings"?  Ints are 12 bytes, strings are 24
bytes (plus the storage for the string), None is 8 bytes.  It adds up.  More
importantly, small ints, interned strings and None would constantly be
created and freed.  The performance savings of sharing them are probably
much more important.

Finally, from a semantic viewpoint, knowing that None is defined by the
language to be a singleton object allows the more efficient "is" operator to
be used when testing objects against None for equality.  If you allowed many
copies of that object that wouldn't work.

    Dave> We should at least have a special 'debug' mode in which the hidden
    Dave> sharing of objects is disabled for selected modules. 

It might help with your problem but would change the semantics of the
language.

Skip