[Python-Dev] Re: [Python-checkins] python/dist/src/Pythoncompile.c, 2.330, 2.331

Tim Delaney tcdelaney at optusnet.com.au
Mon Oct 25 15:01:39 CEST 2004

Michael Hudson wrote:

> Guido van Rossum <gvanrossum at gmail.com> writes:
>> Haven't seen the bug report, but you do realize that comparing code
>> objects has other applications, and this pretty much kills that.
> Really?  It certainly seemed to me that two code objects from
> different places in the source ought to compare differently... it also
> lead to a real problem (coalescing them in co_consts).  I'm genuinely
> curious as to what other applications comparing code objects might
> have.

Well, one application which *did* turn up problems with comparing code 
objects in it's original form was my autosuper recipe:

Specifically, the way I work out what function I'm in:

    frame = sys._getframe().f_back
    code = frame.f_code
    name = code.co_name

    # Find the method we're currently running by scanning the MRO and 
    # the code objects - when we find a match, that's the class whose method
    # we're currently executing.

    for c in type(self).__mro__:
            m = getattr(c, name)
        except AttributeError:

        if m.func_code is code:
            return _super(super(c, self), name)

I originally compared the code objects using ==, which did give false 
positives - hence the change to `is`. Using `is` is correct in this case no 
matter what, but if co_firstlineno was checked in the comparison, == would 
have also have worked (although slower).

BTW, I've just realised that this may not be a sufficient check in all 
cases, since you can change the code object a function uses - I think I'll 
write a new test that does just that ...

I can't think of an application where the current behaviour would be of 
great benefit. It's always possible to create a tuple of the fields you want 
in the comparison. Unless it caused a drop in performance, I'd be in favour 
of only having identity comparison for code objects.

Tim Delaney 

More information about the Python-Dev mailing list