[Python-Dev] Re: [Python-checkins]
python/dist/src/Pythoncompile.c, 2.330, 2.331
Michael Hudson
mwh at python.net
Tue Oct 26 13:31:44 CEST 2004
"Phillip J. Eby" <pje at 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
More information about the Python-Dev
mailing list