RetroSearch Browse

Mon Oct 25 20:05:39 CEST 2004 · http://mail.python.org/pipermail/python-dev/2004-October/049625.html

On Mon, 25 Oct 2004 09:36:18 -0700, Guido van Rossum
<gvanrossum at 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

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

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

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