Why doesn't Python have static variables?

One alternative to a class is a function attribute:

def foo(arg):
    if not hasattr(foo, 'cache'):
        foo.cache = get_data_dict()
    return foo.cache[arg]

While a class is probably cleaner, this technique can be useful and is nicer, in my opinion, then a global.

In Python 3, I would use a closure:

def makefoo():
    x = 0
    def foo():
        nonlocal x
        x += 1
        return x
    return foo

foo = makefoo()

print(foo())
print(foo())

I think most uses of local static variables is to simulate generators, that is, having some function which performs some iteration of a process, returns the result, but mantains the state for the subsequent invocation. Python handles this very elegantly using the yield command, so it seems there is not so much need for static variables.

It's a design choice.

I'm assuming Guido thinks you don't need them very often, and you never really need them: you can always just use a global variable and tell everyone to keep their greasy paws offa' your variable ;-)

For caching or memoization purposes, decorators can be used as an elegant and general solution.

The question is very old, but I think, the correct answer has not been given.

The actual reason for Python as a programming language to not have C-style static variables, seems to be a very personal issue of Guido van Rossum. To me, it seems he likely found the distinction between lifetime scope and visibility scope too complicated or inconvenient. Except for maybe special cases that I am not aware of, Python does not have encapsulation of variables in functions or classes.

How does visibility or encapsulation relate to static variables?

Static variables behave to global variables like private members behave to public members. Sure, there is name mangling but the variable is still accessible and it doesn't provide actual encapsulation. Nested static variables convey information and guarantees of inaccessibility which non-static variables do not.

Same story for C-style static variables. They have global scope but are private to the function, file or code scope in which they are defined. It's the same concept as a private static variable in OOP, just that it can be defined in functions. In Python, however, when a static class variable is accessible to one function, it is also accessible to others. There is no fine-grain setting to control visibility of certain variables.

Generators or classes do not convey the full meaning of static variables

The coherence (belongingness) between a variable and a unit of code can certainly not be expressed in the same way using global variables. Generators and classes are not static either and without being static, they suffer from the same problem as non-static variables: access to them cannot be restricted to a certain region of code. In order to use a generator or class instance, you need to carry it around, and it is gone as soon as it goes out of scope.

A global variable does not convey the same meaning as a C-style static variable, the meaning of only being used by some limited region of code. Effectively, global variables are much more difficult to refactor than static variables.

Design options

Guido actually had two options for getting rid of having two different scopes, by either removing the concept of lifetime scope or the concept of visibility scope.

I could find more arguments for removing lifetime scope (memory management) over visibility scope (data protection), being easier to use, better maintainable and easier to understand or learn. In analogy, words in natural language do not have a lifetime either, just context and visibility.

But removing visibility is easier to implement and rather conservative. The first languages did not have a visibility concept at all, such as machine and Assembly languages. And extra visibility scoping is simply the option that Guido decided to remove. Therefore, you still have keywords such as del which is probably a remnant of old-school manual memory management instead of managing variables by visibility concepts.

What can we do about it?

And since others provided their way of simulating static variables, here is mine:

def foo():
    global bar
    if 'bar' not in globals(): bar = 0 # default value
    # use `bar` here

It makes trouble when the name is also used by other functions, but as there is no encapsulation anyways, it might be a good idea to express coherence better by using specialized names.

The answer's pretty much the same as why nobody uses static methods (even though they exist). You have a module-level namespace that serves about the same purpose as a class would anyway.

An ill-advised alternative:

You can also use the side-effects of the definition time evaluation of function defaults:

def func(initial=0, my_static=[])
  if not my_static:
    my_static.append(initial)

   my_static[0] += 1
  return my_static[0]

print func(0), func(0), func(0)

Its really ugly and easily subverted, but works. Using global would be cleaner than this, imo.

From one of your comments: "I'd like to use them to cache things loaded from disk. I think it clutters the instance less, if I could assign them to the function"

Use a caching class then, as a class or instance attribute to your other class. That way, you can use the full feature set of classes without cluttering other things. Also, you get a reusable tool.

This shows that on SO it always pays off to state one's problem instead of asking for a specific, low level solution (e.g. for a missing language feature). That way, instead of endless debates about simulating "static" (a deprecated feature from an ancient language, in my view) someone could have given a good answer to you problem sooner.