I know this has been in the docs for a while, but why aren't multi-line strings allowed? A quick test shows the implementation allows them, though I suppose strings inside stmt or setup may get indented differently than the user intends.

Because we reindent the user's code by replacing \n (it's a naive reindentation, not based on textwrap and possibly because of historical reasons). Maybe we should instead use dedent() followed by indent(), in which case that could be ok I guess. However, this should be a separate issue.

Hm, at least for the new global_setup that doesn't apply. But even for the existing parameters I'm not sure multi-line strings are prohibited as the docs suggest or just may produce unexpected results (due to reindenting). Regardless we can open a separate issue to discuss a docs change.

Yes, let's discuss it separately.

Why execute it separately?

Are you talking about the code variable? or the local namespace?

Actually, it would have been fine to use the prefix approach as for the others, but the problem would be with variables declared at the global setup phase that aren't visible inside the inner function: ./python -m timeit -n1 -g 's=1' 'print(s)' (they are not visible because we use a specific global dict and a specific local dict as well)

s=1

def inner(_it, _timer):
    pass
    _t0 = _timer()
    for _i in _it:
        print(s)  # NameError
        pass
    _t1 = _timer()
    return _t1 - _t0

Therefore, I need to pick all variables that are declared in the global scope and make them available in the function (but global_ns doesn't have those variables yet). Or am I wrong here?

The inner function will capture variables created by the global setup if use the same dict for globals and locals.

        exec(code, global_ns, global_ns)
        self.inner = global_ns["inner"]

Of course, inner should be renamed to avoid possible conflicts.

I don't know what approach is better. I only say that there is other approach and we should consider it it see what is better.

I've considered renaming all the internal variables in the template with a suffix os.urandom(8).hex() but felt that it shouldn't have been part of this PR.

The inner function will capture variables created by the global setup if use the same dict for globals and locals.

        exec(code, global_ns, global_ns)
        self.inner = global_ns["inner"]

Of course, inner should be renamed to avoid possible conflicts.

I don't know what approach is better. I only say that there is other approach and we should consider it it see what is better.