#5341: fix "builtin" where used as an adjective ("built-in" is correct).
diff --git a/Doc/faq/library.rst b/Doc/faq/library.rst
index b672a66..9c458da 100644
--- a/Doc/faq/library.rst
+++ b/Doc/faq/library.rst
@@ -25,10 +25,10 @@
Where is the math.py (socket.py, regex.py, etc.) source file?
-------------------------------------------------------------
-If you can't find a source file for a module it may be a builtin or dynamically
-loaded module implemented in C, C++ or other compiled language. In this case
-you may not have the source file or it may be something like mathmodule.c,
-somewhere in a C source directory (not on the Python Path).
+If you can't find a source file for a module it may be a built-in or
+dynamically loaded module implemented in C, C++ or other compiled language.
+In this case you may not have the source file or it may be something like
+mathmodule.c, somewhere in a C source directory (not on the Python Path).
There are (at least) three kinds of modules in Python:
@@ -359,7 +359,7 @@
In theory, this means an exact accounting requires an exact understanding of the
PVM bytecode implementation. In practice, it means that operations on shared
-variables of builtin data types (ints, lists, dicts, etc) that "look atomic"
+variables of built-in data types (ints, lists, dicts, etc) that "look atomic"
really are.
For example, the following operations are all atomic (L, L1, L2 are lists, D,
@@ -502,9 +502,9 @@
:func:`os.read` is a low-level function which takes a file descriptor, a small
integer representing the opened file. :func:`os.popen` creates a high-level
-file object, the same type returned by the builtin :func:`open` function. Thus,
-to read n bytes from a pipe p created with :func:`os.popen`, you need to use
-``p.read(n)``.
+file object, the same type returned by the built-in :func:`open` function.
+Thus, to read n bytes from a pipe p created with :func:`os.popen`, you need to
+use ``p.read(n)``.
How do I run a subprocess with pipes connected to both input and output?
@@ -603,10 +603,11 @@
which in turn are a medium-level layer of abstraction on top of (among other
things) low-level C file descriptors.
-For most file objects you create in Python via the builtin ``file`` constructor,
-``f.close()`` marks the Python file object as being closed from Python's point
-of view, and also arranges to close the underlying C stream. This also happens
-automatically in f's destructor, when f becomes garbage.
+For most file objects you create in Python via the built-in ``file``
+constructor, ``f.close()`` marks the Python file object as being closed from
+Python's point of view, and also arranges to close the underlying C stream.
+This also happens automatically in ``f``'s destructor, when ``f`` becomes
+garbage.
But stdin, stdout and stderr are treated specially by Python, because of the
special status also given to them by C. Running ``sys.stdout.close()`` marks