On Wed, Oct 8, 2014 at 12:24 AM, Marco Buttu <marco.bu...@gmail.com> wrote: > Is it too late for changing the name of the `builtin` namespace in something > like, for instance, `root` namespace, or using the name "core" > (inspect.iscore(), types.CoreFunctionType, ecc.) to indicate "written in C"?
Yes, I think it's too late to change that. But it's no different from any other word that has more than one variant of meaning; you have to cope with the collisions. Is there any situation where it's ambiguous? There are builtin name bindings, and there are built-in functions. The former are provided by the language core and are thus available by default; the latter are provided by the language core and thus do not provide __code__. There's a connection between the meanings, but they aren't identical. What's a function? Obviously something created with def or lambda is. Is a class a function? Is an object with a __call__ method a function? Is a list comprehension a function? In different senses, all of them are; but maybe what you want to ask is not "is this a function" but "is this callable" (list comps aren't), or "does this create a new local scope", or "does this have __code__" or something. Yet the meanings of "function" are all related (mostly by external usage; list comps by internal functionality), so it wouldn't make sense to decry the collisions on that word. I do see your issue, but I don't think this can be changed, nor is worth changing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
