Eugene Toder <elto...@gmail.com> added the comment:

It appears that

* co_name was added to hash and cmp in this check-in by Guido:
http://hg.python.org/cpython-fullhistory/diff/525b2358721e/Python/compile.c
I think the reason was to preserve function name when defining multiple 
functions with the same code in one function or module. (By default function 
gets it's name from code, but only one code object will be preserved, since all 
constants in a function are stored in a dict during compilation).

* co_firstlineno was added to cmp (but not hash) in this check-in by Brett:
http://hg.python.org/cpython-fullhistory/rev/8127a55a57cb
In an attempt to fix this bug: 
http://www.mail-archive.com/python-bugs-list@python.org/msg02440.html
It doesn't actually fix the bug and makes hash inconsistent with cmp. I'm not 
convinced that the bug is valid -- why would you care if identical lambdas 
share or not share the code?


Both changes seem come from a tension between code object's original intention 
to compare "functionally equivalent" codes equal and side-effects of constants 
de-duplication in a function (loss of function name, broken breakpoints and 
line numbers in a debugger).
I can think of 2 ways to address this. Change hash/cmp back to ignore co_name 
and co_firstlineno and then:

1) Never dedup codes, or only dedup codes with the same co_firstlineno (can 
compare co_name too, but I can't think of a way to create 2 named funcs on the 
same line). This is pretty much what the current code does.

2) Separate "debug information" (co_filename, co_name, co_firstlineno, 
co_lnotab) from code object into a separate object. Construct a function from 
both objects. Allow de-duplication of both. This will always preserve all 
information in a function, but allows to share code object between identical 
functions. This is a much more intrusive change, though, e.g. frame will need a 
reference to debug information.

----------
nosy: +Jeremy.Hylton, brett.cannon, ncoghlan

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11983>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to