RetroSearch Browse

Tue Oct 26 13:31:44 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-October/049631.html

"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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-October/049631.html below:

[Python-Dev] Re: [Python-checkins] python/dist/src/Pythoncompile.c, 2.330, 2.331