'is' behaving differently in script and interactive shel

[rathinaveluthiruvenkatam]

BPO	37728
Nosy	@eryksun, @remilapeyre

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2019-07-31.09:12:48.902>
created_at = <Date 2019-07-31.08:16:38.096>
labels = ['invalid', 'type-bug', '3.7']
title = "'is'  behaving differently in script and interactive shel"
updated_at = <Date 2019-07-31.09:12:48.899>
user = 'https://bugs.python.org/rathinaveluthiruvenkatam'

bugs.python.org fields:

activity = <Date 2019-07-31.09:12:48.899>
actor = 'eryksun'
assignee = 'none'
closed = True
closed_date = <Date 2019-07-31.09:12:48.902>
closer = 'eryksun'
components = []
creation = <Date 2019-07-31.08:16:38.096>
creator = 'rathinavelu thiruvenkatam'
dependencies = []
files = []
hgrepos = []
issue_num = 37728
keywords = []
message_count = 3.0
messages = ['348790', '348791', '348794']
nosy_count = 3.0
nosy_names = ['eryksun', 'remi.lapeyre', 'rathinavelu thiruvenkatam']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue37728'
versions = ['Python 3.7']

[rathinaveluthiruvenkatam]

af=1.1
bf=1.1
print(f'{af==bf},{af is bf}, {bf is af}' )

""" Script outputs
True,True, True.

On Shell
af=1.1
bf=1.1
print(f'{af==bf},{af is bf}, {bf is af}' )
True,False, False
"""

[remilapeyre]

Hi rathinavelu thiruvenkatam, cPython has some optimizations where some immutable constants will be folded in the same object to save memory so this is not a bug, it's just that those optimization are not run when typing directly in the shell.

You should just use == to compare floats.

[eryksun]

The CPython interpreter doesn't centrally cache and reuse float objects, and even if it did that would be an implementation detail, like what it does with small int objects and strings.

What you're seeing at the module level is a compilation side effect. The compiler is free to reuse immutable constants in a code object. For example:

    >>> code = compile('af=1.1\nbf=1.1', '', 'exec')
    >>> dis.dis(code)
      1           0 LOAD_CONST               0 (1.1)
                  2 STORE_NAME               0 (af)

  2           4 LOAD_CONST               0 (1.1)
              6 STORE_NAME               1 (bf)
              8 LOAD_CONST               1 (None)
             10 RETURN_VALUE

In the above case, both af and bf are initialized with the same 1.1 constant float object, which is at index 0 of the code object's tuple of constants:

    >>> code.co_consts
    (1.1, None)

But if we run af=1.1 and bf=1.1 as separate statements in the REPL shell, the statements are compiled separately, and af and bf won't necessarily reference the same float object.

Don't expect two immutable objects that have the same value to be the same object -- unless it's a singleton such as None and Ellipsis:

    >>> type(None)() is None
    True
    >>> type(Ellipsis)() is Ellipsis
    True

Or an n-way extension of this case, such as bool in Python 3:

    >>> bool(0) is False
    True
    >>> bool(1) is True
    True

The consequences of immutability on object identity are discussed briefly in the final paragraph of "3.1 Objects, values, and types" [1]. Offhand, I don't know where the specific implementation details of CPython builtin immutable types and compiler behavior are discussed, if it's discussed at all.

[1] https://docs.python.org/3/reference/datamodel.html#objects-values-and-types