[Python-Dev] Re: [Python-checkins]
python/dist/src/Pythoncompile.c, 2.330, 2.331
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
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)
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.
More information about the Python-Dev