Muddleheaded use of the "built-in" term

[Chris Angelico]

On Wed, Oct 8, 2014 at 12:24 AM, Marco Buttu <marco.buttu at 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