Python Iterables struggling using map() built-in

Steven D'Aprano steve+comp.lang.python at pearwood.info
Thu Dec 11 18:28:51 EST 2014


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




More information about the Python-list mailing list