Number assignment should be simple enough:

from x1428 import e
a = 1428
b = 1428
c = a is b
print("1428 is 1428 = " + str(c)) #as we expected
print("All three are 1428") #just prove they are all the same
print(a) 
print(b)
print(e)
c = e is a #are they the same?
print("What should c be, it is = " + str(c))
# the file x1428.py contains a single line, being:
#   e = 1428

# GENERATES:
1428 is 1428 = True
All three are 1428
1428
1428
1428
What should c be, it is= False

#the "comparison" of e with a is False because Python created an object
# for e and a different object for a, shared by both a and b.  The is verb
# compares the object addresses, not the values or contents of the objects.
# Yet, no obvious reason would be apparent to any programmer.




             

And, just to compare, change the 1428 values to 14 in the test script and the imported file and try again

from x14 import e
a = 14
b = 14
c = a is b
print("14 is 14 = " + str(c)) #as we expected
print("All three are 14") #just prove they are all the same
print(a) 
print(b)
print(e)
c = e is a #are they the same?
print("What should c be, it is = " + str(c))
# the file x14.py contains a single line, being:
#   e = 14

# GENERATES:
14 is 14 = True
All three are 14
14
14
14
What should c be, it is= True

#the "comparison" of e with a is True because Python used a pre-existing
# object for a, b and e.   An arbitrary decision was made to use the same 
# object rather than generate one.  How would anyone know that in this
# case it chose to use the same objevt but in the previous example it 
# did not.  We could have code where the arbitary decision of Python 
# causes it to fail just because we changed a value.  But, WORSE, Python
# may even chose to change the arbitary-ness since it is not documented,
# and so even without changing the numbers the code could start to 
# operate differently.




             

How is it a good choice that code that uses 14 as a constant behaves so differently to code that replaced that constant with 1428?

Dictionaries are amazing,

x = {True: 'yes', 1: 'no',1.0: 'Really'} #create and initialize a dict
print(x)


#Generates:
{True: 'Really'}

#even though we appear to have created a dictionary with three entries, 
# Python chose to see each of True, 1 and 1.0 as the same index into that
# dictionary and so the second and third values overwrite the first.  But
# it does NOT choose to overwrite the names of the index.

             

How complex can this one liner be?

And wouldn't you expect the output to be simple:

x = (n for n in [1,2,3])
print(2 in x)
print(2 in x)

#generates:
True
False

#Python made a generator with the first x= line.  The in lines used an iterator
# on that generators.  Iterators do not reset so the first print used the 
# iterator and moved it past the value, so it was not available to the second.
# What other language would allow the adding of a "print" statement ahead of
# another executable line to change the effect of the executable line?

             

When even a print statement is not deterministic we have to question readability.

There are so many more, I just like the few above examples.

The reader will probably agree that these are not complex statements using esoteric features of the language. There are no decorators, list comprehensions, etc and even the generator is incredibly confusing.