RetroSearch Browse

Tue Oct 26 18:01:29 CEST 2004 · https://mail.python.org/pipermail/python-dev/2004-October/049634.html

At 12:31 PM 10/26/04 +0100, Michael Hudson wrote:
>"Phillip J. Eby" <pje at 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.

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

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

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