Here is a patch which removes (almost all) mentions of Python long type from docstrings, exception messages and comments.

For msilib, 'int numbers' should just be 'ints' or 'integers'.
---
For PC/winreg.c '''\
PyDoc_STRVAR(PyHKEY_Detach_doc,
"key.Detach() -> int\n"
...
"On 64 bit windows, the result of this function is a long integer");'''

This last line should be deleted rather than modified, as its only point is to override the signature declaration of returning int.
---
I cannot vouch for this change:
-/* necessary to make sure types aren't coerced (e.g., int and long) */
+/* necessary to make sure types aren't coerced (e.g., float and complex) */
I presume you thought about it carefully in context.
---
The rest of the changes look grammatically correct. I cannot be sure about the executable code changes.

New changeset 4d62a62ba44d by Serhiy Storchaka in branch '3.3':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/4d62a62ba44d

New changeset 0872257752c2 by Serhiy Storchaka in branch 'default':
Issue #18783: Removed existing mentions of Python long type in docstrings,
http://hg.python.org/cpython/rev/0872257752c2

Thank you Ezio and Terry for reviews.

> I presume you thought about it carefully in context.

Yes. Here can be any different types for which instances can be equal (1 == 1L, 1.0 == 1.0+0.0j).

> This kind of changes are a bit out of place in a patch like this.  They risk to
> introduce subtle problems and might go unnoticed during commit reviews.

I reverted code back to PyErr_SetString.

The only nontrivial changes are in Lib/pickletools.py, Lib/test/test_itertools.py and Lib/test/test_long.py (removed redundant handling of 'L' suffix in long representation).