Muddleheaded use of the "built-in" term

Marco Buttu marco.buttu at gmail.com
Tue Oct 7 15:24:54 CEST 2014


I always thought the builtin objects were those we can get from the 
`builtins` module, that is those always available. In fact the "Built-in 
Functions" documentation:

https://docs.python.org/3/library/functions.html

says: """The Python interpreter has a number of functions and types 
built into it that are always available. They are listed here in 
alphabetical order""". The functions in the documentation list, as 
expected, are the same functions we get from the `builtins` module.

Now, is `math.sin` builtin? Of course not, because it is not an 
attribute of builtins:

 >>> import builtins
 >>> hasattr(builtins, 'sin')
False

and in fact it is not always available:

 >>> sin
Traceback (most recent call last):
     ...
NameError: name 'sin' is not defined

But what happens if I want to check by using `inspect.isbuiltin`? The 
answer surprises me:

 >>> import inspect
 >>> print(inspect.isbuiltin.__doc__.split('\n')[0])
Return true if the object is a built-in function or method.
 >>> import math
 >>> inspect.isbuiltin(math.sin)
True

That's because the term "built-in" here means "written in C", as 
explained here:

https://docs.python.org/3/library/types.html#types.BuiltinMethodType

So, we have built-in objects that are always available, whose names live 
in the builtin namespace, and other built-in objects that do not live in 
the builtin namespace :/ By using the same word (built-in) to indicate 
either objects written in C or objects referenced by the builtin 
namespace could be a bit muddler for everyone, beginner or not. 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"?

-- 
Marco Buttu



More information about the Python-list mailing list