Question

When are function-local variables are created? For example, in the following code is dictionary d1 created each time the function f1 is called or only once when it is compiled?

def f1():
    d1 = {1: 2, 3: 4}
    return id(d1)

d2 = {1: 2, 3: 4}
def f2():
    return id(d2)

Is it faster in general to define a dictionary within function scope or to define it globally (assuming the dictionary is used only in that function). I know it is slower to look up global symbols than local ones, but what if the dictionary is large?

Much python code I’ve seen seems to define these dictionaries globally, which would seem not to be optimal. But also in the case where you have a class with multiple ‘encoding’ methods, each with a unique (large-ish) lookup dictionary, it’s awkward to have the code and data spread throughout the file.

Answer 1

Local variables are created when assigned to, i.e., during the execution of the function.

If every execution of the function needs (and does not modify!-) the same dict, creating it once, before the function is ever called, is faster. As an alternative to a global variable, a fake argument with a default value is even (marginally) faster, since it’s accessed as fast as a local variable but also created only once (at def time):

def f(x, y, _d={1:2, 3:4}):

I’m using the name _d, with a leading underscore, to point out that it’s meant as a private implementation detail of the function. Nevertheless it’s a bit fragile, as a bumbling calles might accidentally and erroneously pass three arguments (the third one would be bound as _d within the function, likely causing bugs), or the function’s body might mistakenly alter _d, so this is only recommended as an optimization to use when profiling reveals it’s really needed. A global dict is also subject to erroneous alterations, so, even though it’s faster than buiding a local dict afresh on every call, you might still pick the latter possibility to achieve higher robustness (although the global dict solution, plus good unit tests to catch any “oops”es in the function, are the recommended alternative;-).