This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients Kevin Shweh, Tijs Van Oevelen, arigo, donmez, ezio.melotti, fijall, ncoghlan, r.david.murray, rhettinger
Date 2015-12-12.19:28:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1449948489.03.0.15452864495.issue25843@psf.upfronthosting.co.za>
In-reply-to
Content
Interestingly, co_filename is not used as part of the equivalence criteria, so code object equivalence can be fooled across multiple input files.  Fortunately in this case, the false equivalence isn't relied on by the code generator.

  $ cat a.py
  def f():
      return 1

  $ cat b.py
  def f():
      return 1.0

  $ ./python.exe -q
  >>> import a, b
  >>> a.f.__code__ == b.f.__code__  # False equivalence
  True
  >>> a.f()
  1
  >>> b.f()                         # Generated code is correct
  1.0

Besides aliasing int/float/decimal/fraction/complex/bool, codeobj.__eq__() can also alias str/unicode on Python 2.7.  Likewise, 0.0 and -0.0 can be conflated.  NaNs don't seem to be a problem.

I think we should focus on fixing the spec for code object equivalents.  Perhaps the test can be simplified to use (co_firstlineno, co_firstrowno, co_filename).
History
Date User Action Args
2015-12-12 19:28:09rhettingersetrecipients: + rhettinger, arigo, ncoghlan, donmez, ezio.melotti, r.david.murray, fijall, Kevin Shweh, Tijs Van Oevelen
2015-12-12 19:28:09rhettingersetmessageid: <1449948489.03.0.15452864495.issue25843@psf.upfronthosting.co.za>
2015-12-12 19:28:09rhettingerlinkissue25843 messages
2015-12-12 19:28:08rhettingercreate