> > > [GvR]
> > > ...
> > > > The function name is not taken into account for the comparison. Maybe
> > > > it should?
> > >
> > > [CT]
> > > Absolutely, please!
> >
> > [VM]
> > Honestly, no. -O is used for speed, so showing the wrong symbols is
> > okay. It's the same in C.
>
> [CT]
> Not ok, IMHO. If the name is not guaranteed to be valid, why
> should it be there at all? If I write code that relies on
> inspecting those things, then I'm hosed.
I think that you don't want to rely on inspecting the symbol<->code
bindings of an optimized program. In general.
Python is different in this regard, though, because of the standard
introspection facilities. One expects that f.func_code.co_name == 'f'
is always true, although it's not for -O.
A perfect example of a name `conflict' due to object sharing.
The const array optimization is well known. It folds object constants
which have the same value. In this particular case, however, they
don't have the same value, because of the hardcoded function name.
So in the end, it turns out that Chris is right (although not for
the same reason ;-) and it would be nice to fix code_compare.
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4