Deprecating reload() ???

[David MacQuigg]

On Mon, 15 Mar 2004 12:28:50 -0600, Skip Montanaro <skip at pobox.com>
wrote:

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

I think wanting to change numbers in a reloaded module is very common.
  
>Just tell your users, "don't do that".

The problem is the complexity of "that" which they can and cannot do.
Even renouned text authors don't seem to explain it clearly.  I'm
opting now for "don't do anything" to try and make it simple.  By that
I mean - Don't expect reloads to update anything but the reference to
the reloaded module itself.  This is simple, just not very convenient.

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

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 8 bytes to
provide a special None for that reference.

I'm no expert on these implementation issues, but these numbers seem
small compared to the 512MB in a typical modern PC.  I suppose there
are some rare cases where you need to create an array of millions of
references to a single constant.  In those cases the debug mode may be
too much of a burden.  In general, we ought to favor simplicity over
efficiency.

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

Again, as a non-expert, this seems strange.  The burden of comparing a
new object to what is already in memory, using an '==' type of
comparison, must be comparable to simply creating a new object.

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

We would lose some, assuming '==' for these small obects is slower
than 'is', but then you would not have to test '==' on a large number
of objects already in memory each time you define a new integer or
small string.

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

I assume you are referring to the symantics of 'is' when working with
small objects like None, 2, 'abc'.  I agree, that is a problem for the
proposed debug mode.  I don't see a way around it, other than warning
users not to expect modules imported in the debug mode to optimize the
sharing of small objects in memory.  Use 'x == 2' rather than 'x is 2'
if you intend to use the debug mode.

-- Dave