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
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).
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?
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
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
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
-
Guido van Rossum -
Jeremy Hylton -
Michael Hudson -
Phillip J. Eby -
Raymond Hettinger -
Tim Delaney