In the Python 3.7.0 interpreter, the following evaluates to False. In 3.6.4, it was True:

    c,d = 500,500
    c is d

This seems to be because, in some cases, Python 3.7 fails to intern integers inside tuples:

    a = (500,500)
    print(a[0] is a[1]) # False
    
    a = (500,500,42)
    print(a[0] is a[1]) # False
    
    a = (500,500,'42')
    print(a[0] is a[1]) # False
    
    answer = 42
    a = (500,500,answer)
    print(a[0] is a[1]) # True
    
    a = (500,500,[42])
    print(a[0] is a[1]) # True

    a = [500,500]
    print(a[0] is a[1]) # True

I believe the above should all return True.

Another curious case:

    a = (500,500); b = (500,500)
    print(a[0] is b[0]) # True
    print(a[0] is b[1]) # False
    print(a[1] is b[0]) # False
    print(a[1] is b[1]) # True

This was a side-effect of #29469.

Should the AST optimizer "interns" constants?

Thank you for finding it.

I had worked on constant merging. [1]
It didn't fix this case for now.  I'll continue the suspended work.

[1]: https://github.com/methane/cpython/pull/14/files

But it may be a too big to fix only this regression.
How is this regression critical?
If it's important, I'll try to create minimal version of the patch to backport.

This is not only with integers.

>>> a = ((1, 2), (1, 2))
>>> a[0] is a[1]
False
>>> a = ('@#$', '@#$')
>>> a[0] is a[1]
False
>>> a = (1.0, 1.0)
>>> a[0] is a[1]
False

The only exception is short ASCII identifier-like strings (as a side effect of interning them):

>>> a = ('foo', 'foo')
>>> a[0] is a[1]
True

I'm not sure this is a problem which should be resolved.

The language doesn't define anything about this - any program relying on accidental identity is in error itself.

Still, it's nice if a code object's co_consts vector is as short as reasonably possible.  That's a matter of pragmatics, not of correctness.

OK, unless example code this regression affects seriously is shown, I target only 3.8.

The co_consts vector is already as short as possible, except cases when tuples are created at code generation time, but this is not related to this issue (see issue33318 and issue33325).

>>> def f():
...     a = (1.0, 1.0)
...     b = (1.0, 1.0)
... 
>>> f.__code__.co_consts
(None, (1.0, 1.0))
>>> f.__code__.co_consts[1][0] is f.__code__.co_consts[1][1]
False

Fine, Serhiy, so reword it a tiny bit:  it's nice if a code object's co_consts vector references as few distinct objects as possible.  Still a matter of pragmatics, not of correctness.

FYI, same constants are shared even when they are in different tuples on 3.6.

For modules having large constant table containing large integer or floats, non name-like string, and bytes are affected significantly.

Honestly, I don't think that it's a bug. We might enhance Python 3.8 to reduce constants duplication, but there is no need to "fix" Python 3.7.

I also agree that there's no bug here, so I'm marking this an enhancement and removing the regression label.

I think (space) 'performance' would be a better label, as this is strictly an implementation improvement, not a language change.  But we often (usually? sometimes?) limit performance improvements to the 'next version' so we have the alpha/beta/candidate releases to discover possible regressions.

I think this is worth considering just because the pattern is so odd.  But if this is ironed out as part of a broader and better patch, great.

Counting object types in logging/__pycache__/__init__.cpython-38.pyc:

master:
[('r', 1815), (')', 467), ('Z', 339), ('s', 314), ('z', 273), ('c', 157), ('N', 154), ('a', 24), ('F', 14), ('i', 11), ('T', 8)]

GH-8341:
[('r', 1737), (')', 375), ('Z', 339), ('s', 314), ('z', 264), ('c', 157), ('N', 138), ('a', 24), ('F', 14), ('i', 11), ('T', 8)]

It reduced about 5% objects.

I chose logging/__init__ because it's large except tests, and it's written in OO-based. (Large application has many OO-based code).

This is another memory overhead comparison.
It seems merging constants reduces 2~3% memory usage.

import sys, django, flask
sys._debugmallocstats()

### master branch

class   size   num pools   blocks in use  avail blocks
-----   ----   ---------   -------------  ------------
    0      8           1             312           194
    1     16           1             135           118
    2     24           2             198           138
    3     32          22            2690            82
    4     40          62            6214            48
    5     48         149           12465            51
    6     56         254           18260            28
    7     64         354           22300             2
    8     72         208           11589            59
    9     80         124            6173            27
   10     88          59            2708             6
...
# bytes in allocated blocks        =            9,261,952


### merge-const branch

class   size   num pools   blocks in use  avail blocks
-----   ----   ---------   -------------  ------------
    0      8           1             312           194
    1     16           1             135           118
    2     24           1             161             7
    3     32          22            2657           115
    4     40          62            6202            60
    5     48         102            8501            67
    6     56         235           16879            41
    7     64         346           21751            47
    8     72         204           11387            37
    9     80         122            6083            17
   10     88          58            2656            12
...
# bytes in allocated blocks        =            8,919,824

New changeset c2e1607a51d7a17f143b5a34e8cff7c6fc58a091 by Miss Islington (bot) (INADA Naoki) in branch 'master':
bpo-34100: Merge constants recursively (GH-8341)
https://github.com/python/cpython/commit/c2e1607a51d7a17f143b5a34e8cff7c6fc58a091

> New changeset c2e1607a51d7a17f143b5a34e8cff7c6fc58a091 by Miss Islington (bot) (INADA Naoki) in branch 'master'

This change introduced a lot of memory leaks (reference leaks):
https://buildbot.python.org/all/#/builders/1/builds/422

The following change fix "make && ./python -m test -R 3:3 test_code":

diff --git a/Python/compile.c b/Python/compile.c
index acb5cfe29b..cb3e73740d 100644
--- a/Python/compile.c
+++ b/Python/compile.c
@@ -1277,6 +1277,7 @@ merge_consts_recursive(struct compiler *c, PyObject *o)
             else {
                 u = k;
             }
+            Py_DECREF(k);
             Py_INCREF(u);
             PyTuple_SET_ITEM(tuple, i, u);
             i++;
@@ -1288,6 +1289,7 @@ merge_consts_recursive(struct compiler *c, PyObject *o)
             Py_DECREF(key);
             return NULL;
         }
+        Py_DECREF(PyTuple_GET_ITEM(key, 1));
         PyTuple_SET_ITEM(key, 1, new);
     }
 

But I dislike the frozenset branch of merge_consts_recursive(): modifying a tuple is a bad idea. For example, if you replace PyTuple_SET_ITEM() with PyTuple_SetItem(), you get a PyErr_BadInternalCall() because the reference count is greater than 1.

I don't see how to rewrote properly the code, so I reverted (removed) it to let someone else fix the code: PR 10743.

New changeset 1005c84535191a72ebb7587d8c5636a065b7ed79 by Victor Stinner in branch 'master':
bpo-34100: Partially revert merge_consts_recursive() (GH-10743)
https://github.com/python/cpython/commit/1005c84535191a72ebb7587d8c5636a065b7ed79

merge_consts_recursive(): rather than modifying the 'key' tuple, would it make sense to *add* the new key to the cache?

I agree that modifying tuple is bad idea in general case.

But in case of constants, in-place modify is the easiest approach.

Our purpose is "merging" constant.  On the other hand, "build new tuple and
replace old tuple" approach makes two same constant tuples.
If old tuple is referenced from somewhere, we fail to "merging".

So I don't think we need to follow the general principle unless it reduces code.

FYI, we have similar in-place editing for interning already.
https://github.com/python/cpython/blob/master/Objects/codeobject.c#L47-L95

Well, it's up to you. I will review your PR ;-)

New changeset f7e4d3642fbb88f4e6243c952a0e223fb5df1c65 by Victor Stinner (INADA Naoki) in branch 'master':
bpo-34100: compile: Re-enable frozenset merging (GH-10760)
https://github.com/python/cpython/commit/f7e4d3642fbb88f4e6243c952a0e223fb5df1c65

Thanks INADA Naoki! Thanks a simple and cool optimization!

Maybe you might want to document it at https://docs.python.org/dev/whatsnew/3.8.html#optimizations ?