Why doesn't “class” start a new scope like “def” does?

Question

I\'m not entirely sure this is for stackoverflow, so please correct me if not.

i.e. say we have t.py with contents:

class A(object):
    pass
print(\"A:         


        

Answer 1

As Wooble noted in a comment, the class block does create a new scope. The problem is that names in a class block scope are not accessible to scopes nested within that scope. This is mentioned in the documentation:

The scope of names defined in a class block is limited to the class block; it does not extend to the code blocks of methods – this includes comprehensions and generator expressions since they are implemented using a function scope.

I can't find the source of this right now, but somewhere (I think on a StackOverflow question) I found one plausible rationale for this: if the class def were accessible inside nested blocks, method names would shadow global functions, including builtins. This would make it awkward to create classes that have methods with short, simple names, but that also make use of builtin functions of the same name. For instance, you couldn't do this:

class SomeDataStructure(object):
    def sum(self):
        return sum(self._data)
    def otherCalc(self):
        return sum(item for item in somethingElse)

If the class block were in scope within methods, this would cause an infinite recursion, since the inner sum call would have access to the method name and would call that method instead of the builtin sum function. Likewise, other methods such as the the otherCalc method would no longer have access to the global sum function for their own use, but would always be getting the method. An answer to another SO question describes this by saying "it's because you're supposed to use self to access methods in Python".

Now, that argument really only makes sense for functions inside classes, because function bodies aren't executed when the def is, but class bodies are executed when the class statement is. However, I think if you combine what I said above with the notions from this blog post, you get a reasonable rationale. Namely, nested classes weren't --- and still aren't --- considered a style that's worth supporting. Functions inside classes, though, are of course commonplace. The simplest way to handle the function-inside-a-class use case was to make the class block not pass on its names to any nested scopes. It would arguably be better if it passed on its names to nested classes but not nested functions, but that would be a more complex rule, and no one cares enough about supporting nested classes to make it worthwhile.