Take the case a = (1, 2, 3). I think what is going on is that the compiler generates the tuple (1, 2, 3) at compile time (because it can't vary).

Consider this function:

x = 0
def cb(_):
    global x, y
    y = (x,2,3)
    x += 1

This does allocate because each time the function is called a new tuple has to be created. I think this applies to a number of your non-allocating examples: the compiler creates constants where it can.

Yes, I agree that's what's going on there, and similarly with t = 3.4 - although floats are heap allocated, this is a define-time constant so it is heap allocated when the function is defined not when it is run.

x = 1; y = 2; a = x, y allocates, but interestingly x = 1; y = 2; a, b = x, y doesn't, so the 'pack and unpack' pattern is optimised to avoid a throwaway allocation. (It's still quite a bit slower to do a, b = x, y than a = x; b = y, though, even though it doesn't allocate on the heap.)

for i in range(n): print(i) also doesn't allocate even when n isn't constant, which is surprising but pleasing.

(Or is the nested function compiled/byte-compiled just once, and the measured allocation and performance difference just the creation of a lightweight closure structure to hold the captured variables?)

Hmm, I think the runtime figures might confirm this idea, having done a bit of experimenting.

foo() defined as

def foo():
  def bar():
    return 0
  return bar()

runs about 1000 cycles slower than

def bar():
  return 0
def foo():
  return bar()

But foo() defined as

def foo():
  def bar():
    x = 0
    x = x + 1
    [... 1000s more increment lines ...]
    x = x + 1
    return x
  return bar()

is also only about 1000 cycles slower than

def bar():
  x = 0
  x = x + 1
  [... 1000s more increment lines ...]
  x = x + 1
  return x
def foo():
  return bar()

Thus it seems to be a constant-time difference not a difference proportional to code length, which implies some kind of environment/closure allocation, not a runtime code generation. That's a relief - python without nested functions would be pretty clunky.

The following allocates (fails with a memory error):

from pyb import Timer

x = 0
def cb(_):
    global x
    def foo(y):
        return y + 1
    x = foo(x)
    print(x)

cb(0)  # Initial call runs OK
t = Timer(1, freq=1, callback=cb)  # but fails first time it's called in a hard ISR context

Much as I like nested functions and closures, I've never tried creating one in a hard ISR context. Very educational. Obviously the callback runs if I move foo() into the global namespace.

One trick you may be unaware of: you can get a bytecode listing of your code with

$ micropython -v -v my_code.py

where micropython is the Unix build of MP.

Testing for allocation in a repeated hard ISR callback ensures that you can't be led astray by the compiler's useful habit of pre-compiling objects.