Ian Kelly wrote: > A function, on the > other hand, is not well suited to be a namespace, because it's not > expected to provide one.
And that is exactly the point I am making about the inherent conservativeness of Python developers. Functions ARE namespaces, like instances of user-defined classes they have a __dict__ and can carry per-instance state. (If you think that only modules are namespaces, you are badly mistaken. Instances are namespaces too.) This is *not* an accident of implementation, it is a deliberate design choice. Contrast functions with builtin functions: py> def f(): pass ... py> vars(f) {} py> vars(len) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: vars() argument must have __dict__ attribute Although functions are written in pure Python, their type is implemented in C and could easily have been designed to be __dict__-less just like the builtin_function_or_method type. But they weren't. It is a language feature that functions are namespaces. So why don't we use functions as namespaces? We don't use functions as namespaces because nobody thinks of them as namespaces, and we don't think of them as namespaces because nobody uses them as namespaces -- and when somebody tries to break out of that vicious circle, the conservativeness kicks in and the very idea is rejected. I think that there is a legitimate debate to be had as to whether this conservativeness and resistance to change is a good thing or a bad thing, but I don't think that there should be any debate about the reality of the Python community being strongly conservative, compared to the "anything goes" attitude of (say) Ruby, Perl and Lisp programmers. We don't like code that does anything we haven't seen a hundred times before. -- Steven -- https://mail.python.org/mailman/listinfo/python-list