Michael Hudson wrote:
Guido van Rossum
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: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/286195 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 comparing # the code objects - when we find a match, that's the class whose method # we're currently executing. for c in type(self).__mro__: try: m = getattr(c, name) except AttributeError: continue 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