Deprecating reload() ???

[Skip Montanaro]

    Dave> I agree, punt is the right play for now, but I want to make one
    Dave> clarification, in case we need to re-open this question.  The
    Dave> semantic change we are talking about applies only to the 'is'
    Dave> operator, and only to a few immutable objects which are created
    Dave> via a reload of a module in "debug" mode.  All other objects,
    Dave> including those from other modules remain unchanged.  Objects like
    Dave> None, 1, 'abc', which are treated as shared objects in normal
    Dave> modules, will be given a unique ID when loaded from a module in
    Dave> debug mode.  This means you will have to use '==' to test equality
    Dave> of those objects, not 'is'.  Since 'is' is already a tricky,
    Dave> implementation-dependent operator that is best avoided in these
    Dave> situations, the impact of this added option seems far less than
    Dave> "changing the semantics of the language".

Don't forget all the C code.  C programmers know the object which represents
None is unique, so their code generally looks like this snippet from
Modules/socketmodule.c:

        if (arg == Py_None)
                timeout = -1.0;

"==" in C is the equivalent of "is" in Python.  If you change the uniqueness
of None, you have a lot of C code to change.
    
    Dave>     def h23(freq):
    Dave>         s = complex(2*pi*freq)
    Dave>         h0 = PZfuncs.h0
    Dave>         z1 = PZfuncs.z1; z2 = PZfuncs.z2
    Dave>         p1 = PZfuncs.p1; p2 = PZfuncs.p2; p3 = PZfuncs.p3
    Dave>         return h0*(s-z1)*(s-z2)/((s-p1)*(s-p2)*(s-p3))

    Dave> Notice the clarity in that last formula.  

Yeah, but h0, z1, z2, etc are not long-lived copies of attributes in
PZfuncs.  If I execute:

    >>> blah = h23(freq)
    >>> reload(PZfuncs)
    >>> blah = h23(freq)

things will work properly.  It's only long-lived aliases that present a
problem:

    def h23(freq, h0=PZfuncs.h0):
        s = complex(2*pi*freq)
        z1 = PZfuncs.z1; z2 = PZfuncs.z2
        p1 = PZfuncs.p1; p2 = PZfuncs.p2; p3 = PZfuncs.p3
        return h0*(s-z1)*(s-z2)/((s-p1)*(s-p2)*(s-p3))

    Dave> In this case we avoid the problem of local variables out-of-sync
    Dave> with a reloaded module by refreshing those variables with every
    Dave> call to the function.  In other cases, this may add too much
    Dave> overhead to the computation.

Unlikely.  Creating local copies of frequently used globals (in this case
frequently used globals in another module) is almost always a win.  In fact,
it's so much of a win that a fair amount of brain power has been devoted to
optimizing global access.  See PEPs 266 and 267 and associated threads in
python-dev from about the time they were written.  (Note that optimizing
global access is still an unsolved problem in Python.)

Skip