is behave different for integers in 3.6 and 3.7

[GeraldoXexeo]

BPO	36592
Files	testisbehavior.py: A very simple example of the behavior

^{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-04-11.00:01:17.797>
created_at = <Date 2019-04-10.23:55:24.967>
labels = ['interpreter-core', '3.7', 'invalid']
title = 'is behave different for integers in 3.6 and 3.7'
updated_at = <Date 2019-04-11.01:52:59.579>
user = 'https://bugs.python.org/GeraldoXexeo'

bugs.python.org fields:

activity = <Date 2019-04-11.01:52:59.579>
actor = 'Shane Smith'
assignee = 'none'
closed = True
closed_date = <Date 2019-04-11.00:01:17.797>
closer = 'eric.smith'
components = ['Interpreter Core']
creation = <Date 2019-04-10.23:55:24.967>
creator = 'Geraldo.Xexeo'
dependencies = []
files = ['48259']
hgrepos = []
issue_num = 36592
keywords = []
message_count = 5.0
messages = ['339900', '339902', '339905', '339913', '339914']
nosy_count = 2.0
nosy_names = ['Geraldo.Xexeo', 'Shane Smith']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue36592'
versions = ['Python 3.6', 'Python 3.7']

[GeraldoXexeo]

# When you run the program:
a,b=300,300
print(a is b)
#you get different results in 3.6 (True) and 3.7 (False)

[ericvsmith]

Python makes no guarantee as to whether an identity test on integers would return True or False. You should not depend on the behavior in any particular version.

[ShaneSmith]

This is the sort of thing that makes me avoid "is" in favor of "==" for most applications. Understanding when two objects point to the same memory requires a deeper understanding of the underlying code than I usually want to delve into.

Anyway, I find it interesting that for 3.7.3:
>>> a, b = 256, 256
>>> a is b
True

>>> a, b = 257, 257
>>> a is b
False

So 2**8 is a magic number, for whatever reason. I'll be sticking with "=="...

[GeraldoXexeo]

"So 2**8 is a magic number, for whatever reason."

Actually, this is true. Accordingly to https://rushter.com/blog/python-integer-implementation/

"Optimization of commonly-used integers
Small integer objects in a range of -5 to 256 are always pre-allocated during initialization. Because Python integers are immutable, we can use them as singletons. Every time you need to create small integer instead of creating new object Python just points to already allocated one. Thereby it saves a lot of space and computation for commonly-used integers.

Interestingly enough, the PyLongObject structure takes at least 28 bytes for every allocated integer and therefore takes three times as much memory as a simple 64-bit C integer."

This are constants

#define NSMALLPOSINTS           257
#define NSMALLNEGINTS           5

You can find the code in:

https://github.com/python/cpython/blob/master/Objects/longobject.c

[ShaneSmith]

Well, then I guess that explains it! Still, like I said, I tend to shy away from features that require such a deep understanding of the implementation in order to avoid "gotchas". "is" does have its uses, but for me they very very rarely come up.