[issue25843] code_richcompare() don't use constant type when comparing code constants

Larry Hastings added the comment: Yes, which doesn't help 3.5.2 final as I don't pull revisions by default after rc1. :p -- ___ Python tracker ___

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: Oh, I fixed the typo in the Misc/NEWS in 3.5 and default branches. -- ___ Python tracker ___

[issue25843] code_richcompare() don't use constant type when comparing code constants

Roundup Robot added the comment: New changeset a36238de31ae by Victor Stinner in branch '3.5': Issue #25843: Fix the NEWS entry https://hg.python.org/cpython/rev/a36238de31ae -- ___ Python tracker

[issue25843] code_richcompare() don't use constant type when comparing code constants

Larry Hastings added the comment: Someone asked on reddit. The Misc/NEWS entry for this reads: Issue #25843: When compiling code, don’t merge constants if they are equal but have a different types. For example, f1, f2 = lambda: 1, lambda: 1.0 is now correctly compiled to two different

[issue25843] code_richcompare() don't use constant type when comparing code constants

Roundup Robot added the comment: New changeset 16f60cd918e0 by Victor Stinner in branch 'default': PEP 511 https://hg.python.org/peps/rev/16f60cd918e0 -- ___ Python tracker

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: > I will probably remove the optimization on frozenset since it's only useful > for AST optimizers (the optimization is a new feature, I considered that it > was worth it to add it Python 3.6 as part of my work on the PEP 511). Hum, it doesn't work:

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: I pushed my latest patch with minor changes in comments. I will wait for buildbots before backporting the change to Python 2.7 and 3.5. For the backport, I will probably remove the optimization on frozenset since it's only useful for AST optimizers (the

[issue25843] code_richcompare() don't use constant type when comparing code constants

Roundup Robot added the comment: New changeset 6c33d4cc9b8f by Victor Stinner in branch 'default': code_richcompare() now uses the constants types https://hg.python.org/cpython/rev/6c33d4cc9b8f -- nosy: +python-dev ___ Python tracker

[issue25843] code_richcompare() don't use constant type when comparing code constants

Roundup Robot added the comment: New changeset 8e0a736b82ff by Victor Stinner in branch '3.5': code_richcompare() now uses the constants types https://hg.python.org/cpython/rev/8e0a736b82ff -- ___ Python tracker

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: Ok, the fix is now pushed to Python 2.7, 3.5 and 3.6. Thanks Tijs Van Oevelen for your bug report ;-) A workaround look to define the two lambda functions on two different lines. Or maybe cast explicitly to float? I don't think that it's a common bug so you

[issue25843] code_richcompare() don't use constant type when comparing code constants

Roundup Robot added the comment: New changeset 9e13d97ceca2 by Victor Stinner in branch '2.7': code_richcompare() now uses the constants types https://hg.python.org/cpython/rev/9e13d97ceca2 -- ___ Python tracker

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: Updated patch version 5. > I meant that set shouldn't be handled in _PyCode_ConstantKey at all. Only > frozenset constants can be considered equal. Sets as well as lists all should > be different. Ok, I dropped support for set type to only keep support for

[issue25843] code_richcompare() don't use constant type when comparing code constants

Serhiy Storchaka added the comment: I meant that set shouldn't be handled in _PyCode_ConstantKey at all. Only frozenset constants can be considered equal. Sets as well as lists all should be different. There is yet one issue with string and bytes literals. When run Python with the -b option:

[issue25843] code_richcompare() don't use constant type when comparing code constants

Serhiy Storchaka added the comment: It looks to me that the patch makes set and frozenset constants to be equal, but makes sets with different order (as {2**62, 1} and {1, 2**62}) differ. And looks you had missed my comments to previous patches. -- stage: -> patch review versions:

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: Patch version 4: Fix _PyCode_ConstantKey: * always return a tuple * create a frozenset/set if input is a set/frozenset, items are unordered * enhance unit tests: compare values using repr() to compare value + type at once * fix reference leak Other minor

[issue25843] code_richcompare() don't use constant type when comparing code constants

STINNER Victor added the comment: And sorry, I missed your comments, it looks like some emails were seen as spam :-/ -- ___ Python tracker ___

[issue25843] code_richcompare() don't use constant type when comparing code constants

Changes by STINNER Victor : -- title: lambdas on the same line may incorrectly share code objects -> code_richcompare() don't use constant type when comparing code constants ___ Python tracker