[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.330, 2.331
Haven't seen the bug report, but you do realize that comparing code objects has other applications, and this pretty much kills that. On Sat, 23 Oct 2004 17:10:09 -0700, rhettinger@users.sourceforge.net <rhettinger@users.sourceforge.net> wrote:
Update of /cvsroot/python/python/dist/src/Python In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30133/Python
Modified Files: compile.c Log Message: SF bug #1048870: call arg of lambda not updating
Index: compile.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v retrieving revision 2.330 retrieving revision 2.331 diff -u -d -r2.330 -r2.331 --- compile.c 29 Sep 2004 23:54:08 -0000 2.330 +++ compile.c 24 Oct 2004 00:10:05 -0000 2.331 @@ -261,6 +261,8 @@ if (cmp) return (cmp<0)?-1:1; cmp = co->co_flags - cp->co_flags; if (cmp) return (cmp<0)?-1:1; + cmp = co->co_firstlineno - cp->co_firstlineno; + if (cmp) return (cmp<0)?-1:1; cmp = PyObject_Compare(co->co_code, cp->co_code); if (cmp) return cmp; cmp = PyObject_Compare(co->co_consts, cp->co_consts);
_______________________________________________ Python-checkins mailing list Python-checkins@python.org http://mail.python.org/mailman/listinfo/python-checkins
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Haven't seen the bug report, but you do realize that comparing code objects has other applications, and this pretty much kills that.
In the OP's situation, two distinct function objects with differing default values were showing up with a non-unique code object. As a result, when the OP's code failed, the traceback message pointed to the wrong like in the file (the first seen function rather than the one executing). If some other code comparison application is more important, I would be happy to reverse this patch and mark the bug as WON'T FIX. While the OP's situation did sent him on a wild goose chase (trying to debug the part of his code that did work), I can't imagine that it comes up often enough to care much about. Raymond
Guido van Rossum <gvanrossum@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. Cheers, mwh (This was my patch that I didn't get around to applying myself). -- In short, just business as usual in the wacky world of floating point <wink>. -- Tim Peters, comp.lang.python
Michael Hudson wrote:
Guido van Rossum <gvanrossum@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: 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
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.
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever? This would be ironic since that's what it *used* to do long ago, and then I thought it would be "better" if "equivalent" code objects compared equal. It seems that there are no real use cases for having a code object equivalence test, so we might as well save the effort. Right? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 25 Oct 2004 09:36:18 -0700, Guido van Rossum <gvanrossum@gmail.com> wrote:
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.
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever? This would be ironic since that's what it *used* to do long ago, and then I thought it would be "better" if "equivalent" code objects compared equal. It seems that there are no real use cases for having a code object equivalence test, so we might as well save the effort. Right?
+1 I can't guess why someone would want to compare code objects for something other than object identity. If someone has a specific use case, there is enough introspection available that they can compare the bytecodes, constants, &c and produce whatever result they want. Jeremy
At 09:36 AM 10/25/04 -0700, Guido van Rossum wrote:
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.
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever?
Isn't that what function objects do now? (for some value of "now") Python 2.3.4 (#1, Jun 13 2004, 11:21:03) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information.
l = [lambda:None for i in 0,1] l[0]==l[1] False l[0].func_code is l[1].func_code True
It would seem that two lambdas with no default arguments, no free variables, and identical code objects would be "equal" if we were using value comparison, rather than identity.
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 09:36 AM 10/25/04 -0700, Guido van Rossum wrote:
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.
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever?
+1
Isn't that what function objects do now? (for some value of "now")
Probably. I don't see the relavence, though.
Python 2.3.4 (#1, Jun 13 2004, 11:21:03) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information.
l = [lambda:None for i in 0,1] l[0]==l[1] False l[0].func_code is l[1].func_code True
What's happened *here* is that two code objects got compiled up for the two lambdas, but they compare equal so only one goes into co_consts.
It would seem that two lambdas with no default arguments, no free variables, and identical code objects would be "equal" if we were using value comparison, rather than identity.
Yes. Cheers, mwh -- GET *BONK* BACK *BONK* IN *BONK* THERE *BONK* -- Naich using the troll hammer in cam.misc
At 12:31 PM 10/26/04 +0100, Michael Hudson wrote:
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 09:36 AM 10/25/04 -0700, Guido van Rossum wrote:
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever?
+1
Isn't that what function objects do now? (for some value of "now")
Probably. I don't see the relavence, though.
Because Guido sounded like he was saying that function objects didn't already do that.
Python 2.3.4 (#1, Jun 13 2004, 11:21:03) [GCC 3.3.1 (cygming special)] on cygwin Type "help", "copyright", "credits" or "license" for more information.
l = [lambda:None for i in 0,1] l[0]==l[1] False l[0].func_code is l[1].func_code True
What's happened *here* is that two code objects got compiled up for the two lambdas, but they compare equal so only one goes into co_consts.
Actually, no. There's only one code object, otherwise this: [lambda:None for i in range(10000)] would somehow create 10000 code objects, which makes no sense. There's simply a 1:1 mapping between function and class suites in a source text, and code objects created in the module's co_consts. Code comparison has nothing to do with it.
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 12:31 PM 10/26/04 +0100, Michael Hudson wrote:
"Phillip J. Eby" <pje@telecommunity.com> writes:
At 09:36 AM 10/25/04 -0700, Guido van Rossum wrote:
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever?
+1
Isn't that what function objects do now? (for some value of "now")
Probably. I don't see the relavence, though.
Because Guido sounded like he was saying that function objects didn't already do that.
Uh, yeah, I clearly wrote that post before I'd drunk enough coffee... Cheers, mwh -- Java sucks. [...] Java on TV set top boxes will suck so hard it might well inhale people from off their sofa until their heads get wedged in the card slots. --- Jon Rabone, ucam.chat
Guido van Rossum wrote:
Well, then perhaps code object comparison (and function object comparison) ought to work the same as 'is', not try to do something clever? This would be ironic since that's what it *used* to do long ago, and then I thought it would be "better" if "equivalent" code objects compared equal. It seems that there are no real use cases for having a code object equivalence test, so we might as well save the effort. Right?
+1 (that's of course what I meant by identity comparison). Were there any use cases you thought of when you made the change? Tim Delaney
participants (6)
-
Guido van Rossum -
Jeremy Hylton -
Michael Hudson -
Phillip J. Eby -
Raymond Hettinger -
Tim Delaney