Remove e.g. and i.e. throughout

.github/CODE_OF_CONDUCT.md

@@ -6,7 +6,7 @@ Please note that all interactions on
 infrastructure is [covered](https://www.python.org/psf/records/board/minutes/2014-01-06/#management-of-the-psfs-web-properties)
 by the [PSF Code of Conduct](https://www.python.org/psf/conduct/),
 which includes all infrastructure used in the development of Python itself
-(e.g. mailing lists, issue trackers, GitHub, etc.).
+(for example, mailing lists, issue trackers, GitHub, etc.).
 
 In general this means everyone is expected to be open, considerate, and
 respectful of others no matter what their position is within the project.

.github/CONTRIBUTING.md

@@ -29,7 +29,7 @@ our workflow that are not covered by a bot or status check are:
 
 ## Setting Expectations
 
-Due to the fact that this project is entirely volunteer-run (i.e. no one is paid
+Due to the fact that this project is entirely volunteer-run (that is, no one is paid
 to work on Python full-time), we unfortunately can make no guarantees as to if
 or when a core developer will get around to reviewing your pull request.
 If no core developer has done a review or responded to changes made because of a

core-developers/committing.rst

@@ -44,7 +44,7 @@ to enter the public source tree. Ask yourself the following questions:
    <https://discuss.python.org/c/core-dev/23>`__.
 
 * **Does documentation need to be updated?**
-   If the pull request introduces backwards-incompatible changes (e.g.
+   If the pull request introduces backwards-incompatible changes (for example,
    deprecating or removing a feature), then make sure that those changes
    are reflected in the documentation before you merge the pull request.
 
@@ -61,14 +61,14 @@ to enter the public source tree. Ask yourself the following questions:
    Make sure that the contributor has signed a `Contributor
    Licensing Agreement <https://www.python.org/psf/contrib/contrib-form/>`_
    (CLA), unless their change has no possible intellectual property
-   associated with it (e.g. fixing a spelling mistake in documentation).
+   associated with it (for example, fixing a spelling mistake in documentation).
    The `CPython CLA Bot <https://github.com/apps/cpython-cla-bot/>`_
    checks whether the author has signed the CLA, and replies in the PR
    if they haven't. For further questions about the CLA
    process, write to [email protected].
 
 * **Were** ``What's New in Python`` **and** ``Misc/NEWS.d/next`` **updated?**
-   If the change is particularly interesting for end users (e.g. new features,
+   If the change is particularly interesting for end users (for example, new features,
    significant improvements, or backwards-incompatible changes), then an
    entry in the ``What's New in Python`` document (in ``Doc/whatsnew/``) should
    be added as well. Changes that affect only documentation generally do not
@@ -97,7 +97,7 @@ For the last two, note the following:
 
 #. **If a change is reverted prior to release**, then the corresponding
    entry is simply removed. Otherwise, a new entry must be added noting
-   that the change has been reverted (e.g. when a feature is released in
+   that the change has been reverted (for example, when a feature is released in
    an alpha and then cut prior to the first beta).
 
 #. **If a change is a fix (or other adjustment) to an earlier unreleased
@@ -107,7 +107,7 @@ For the last two, note the following:
 Changes that require "What's New in Python" entries
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If a change is particularly interesting for end users (e.g. new features,
+If a change is particularly interesting for end users (for example, new features,
 significant improvements, or backwards-incompatible changes), add an entry in
 the "What's New in Python" document (in :cpy-file:`Doc/whatsnew/`)
 in addition to the ``NEWS`` entry.
@@ -130,16 +130,16 @@ or the :pypi:`blurb` tool and its ``blurb add`` command.
 If you are unable to use the tool, then you can create the ``NEWS`` entry file
 manually. The ``Misc/NEWS.d`` directory contains a sub-directory named
 ``next``, which contains various sub-directories representing classifications
-for what was affected (e.g. ``Misc/NEWS.d/next/Library`` for changes relating
+for what was affected (for example, ``Misc/NEWS.d/next/Library`` for changes relating
 to the standard library). The file name itself should be in the format
 ``<datetime>.gh-issue-<issue-number>.<nonce>.rst``:
 
 * ``<datetime>`` is today's date joined with a hyphen (``-``) to your current
-  local time, in the ``YYYY-MM-DD-hh-mm-ss`` format (e.g. ``2017-05-27-16-46-23``).
-* ``<issue-number>`` is the issue number the change is for (e.g. ``12345``
+  local time, in the ``YYYY-MM-DD-hh-mm-ss`` format (for example, ``2017-05-27-16-46-23``).
+* ``<issue-number>`` is the issue number the change is for (for example, ``12345``
   for ``gh-issue-12345``).
 * ``<nonce>`` is a unique string to guarantee that the file name is
-  unique across branches (e.g. ``Yl4gI2``). It is typically six characters
+  unique across branches (for example, ``Yl4gI2``). It is typically six characters
   long, but it can be any length of letters and numbers. Its uniqueness
   can be satisfied by typing random characters on your keyboard.
 
@@ -159,7 +159,7 @@ the reader to have read the actual diff for the change.
 
 The contents of a ``NEWS`` file should be valid reStructuredText. An 80 character
 column width should be used. There is no indentation or leading marker in the
-file (e.g. ``-``). There is also no need to start the entry with the issue
+file (for example, ``-``). There is also no need to start the entry with the issue
 number since it is part of the file name. You can use
 :ref:`inline markups <rest-inline-markup>` too. Here is an example of a ``NEWS``
 entry::

core-developers/motivations.rst

@@ -80,7 +80,7 @@ participating in the CPython core development process:
    country of residence.
 
    Include a "Crowdfunding" bullet point with a link if you'd like to highlight
-   crowdfunding services (e.g. Patreon) that folks can use to support your core
+   crowdfunding services (for example, Patreon) that folks can use to support your core
    development work.
 
    Include additional bullet points (without links) for any other affiliations
@@ -116,7 +116,7 @@ participating in the CPython core development process:
    applications and test harnesses from open source components.
 
    Note: prior to August 2023, Alyssa used her birth name (Nick Coghlan). Some records
-   (e.g. mailing list archives, version control history) will still reference that name.
+   (for example, mailing list archives, version control history) will still reference that name.
 
 .. topic:: Steve Dower (United States/Australia)
 

developer-workflow/c-api.rst

@@ -219,7 +219,7 @@ Moving an API from the public tier to Unstable
 * Expose the API under its new name, with the ``PyUnstable_`` prefix.
   The ``PyUnstable_`` prefix must be used for all symbols (functions, macros,
   variables, etc.).
-* Make the old name an alias (e.g. a ``static inline`` function calling the
+* Make the old name an alias (for example, a ``static inline`` function calling the
   new function).
 * Deprecate the old name, typically using :c:macro:`Py_DEPRECATED`.
 * Announce the change in the "What's New".
@@ -255,7 +255,7 @@ Moving an API from unstable to public
 -------------------------------------
 
 * Expose the API under its new name, without the ``PyUnstable_`` prefix.
-* Make the old ``PyUnstable_*`` name be an alias (e.g. a ``static inline``
+* Make the old ``PyUnstable_*`` name be an alias (for example, a ``static inline``
   function calling the new function).
 * Announce the change in What's New.
 
@@ -393,7 +393,7 @@ Adding a new definition to the Limited API
 
     #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x03yy0000
 
-  with the ``yy`` corresponding to the target CPython version, e.g.
+  with the ``yy`` corresponding to the target CPython version, for example,
   ``0x030A0000`` for Python 3.10.
 - Append an entry to the Stable ABI manifest, ``Misc/stable_abi.toml``
 - Regenerate the autogenerated files using ``make regen-limited-abi``.
@@ -426,7 +426,7 @@ To add a test file:
 
 - Add a C file ``Modules/_testcapi/yourfeature_limited.c``. If that file
   already exists but its ``Py_LIMITED_API`` version is too low, add a version
-  postfix, e.g. ``yourfeature_limited_3_12.c`` for Python 3.12+.
+  postfix, for example, ``yourfeature_limited_3_12.c`` for Python 3.12+.
 - ``#define Py_LIMITED_API`` to the minimum limited API version needed.
 - ``#include "parts.h"`` after the ``Py_LIMITED_API`` definition
 - Enclose the entire rest of the file in ``#ifdef LIMITED_API_AVAILABLE``,

developer-workflow/development-cycle.rst

@@ -36,8 +36,8 @@ Some examples of release tags: ``v3.7.0a1``, ``v3.6.3``, ``v2.7.14rc1``.
 Branches
 --------
 
-There is a branch for each *feature version*, whether released or not (e.g.
-3.7, 3.8).
+There is a branch for each *feature version*, whether released or not (for
+example, 3.7, 3.8).
 
 
 .. _indevbranch:
@@ -57,7 +57,7 @@ For versions 3.4 and before, this was conventionally done when the final
 release was cut (for example, 3.4.0 final).
 
 Starting with the 3.5 release, we create the release maintenance branch
-(e.g. 3.5) at the time we enter beta (3.5.0 beta 1).  This allows
+(``3.5``) at the time we enter beta (3.5.0 beta 1).  This allows
 feature development for the release 3.n+1 to occur within the main
 branch alongside the beta and release candidate stabilization periods
 for release 3.n.
@@ -89,7 +89,7 @@ since most readers access the `stable documentation <https://docs.python.org/3/>
 rather than the `development documentation <https://docs.python.org/dev/>`__.
 
 A new maintenance branch is normally created when the next feature release
-cycle reaches feature freeze, i.e. at its first beta pre-release.
+cycle reaches feature freeze, that is, at its first beta pre-release.
 From that point on, changes intended for remaining pre-releases, the final
 release (3.x.0), and subsequent bugfix releases are merged to
 that maintenance branch.
@@ -131,7 +131,7 @@ End-of-life branches
 The code base for a release cycle which has reached end-of-life status
 is frozen and no longer has a branch in the repo.  The final state of
 the end-of-lifed branch is recorded as a tag with the same name as the
-former branch, e.g. ``3.3`` or ``2.6``.
+former branch, for example, ``3.3`` or ``2.6``.
 
 The :ref:`versions` page contains list of active and end-of-life branches.
 
@@ -191,7 +191,7 @@ Release Candidate (RC)
 
 A branch preparing for an RC release can only have bugfixes applied that have
 been reviewed by other core developers.  Generally, these issues must be
-severe enough (e.g. crashes) that they deserve fixing before the final release.
+severe enough (for example, crashes) that they deserve fixing before the final release.
 All other issues should be deferred to the next development cycle, since
 stability is the strongest concern at this point.
 
@@ -227,13 +227,13 @@ repositories are expected to relate to the Python language, the CPython
 reference implementation, their documentation and their development workflow.
 This includes, for example:
 
-* The reference implementation of Python and related repositories (i.e. `CPython <https://github.com/python/cpython>`_)
-* Tooling and support around CPython development (e.g. `pyperformance <https://github.com/python/pyperformance>`_, `Bedevere <https://github.com/python/bedevere>`_)
-* Helpers and backports for Python/CPython features (e.g. `typing_extensions <https://github.com/python/typing_extensions>`_, `typeshed <https://github.com/python/typeshed>`_, `tzdata <https://github.com/python/tzdata>`_, `pythoncapi-compat <https://github.com/python/pythoncapi-compat>`_)
-* Organization-related repositories (e.g. the `Code of Conduct <https://github.com/python/pycon-code-of-conduct>`_, `.github <https://github.com/python/.github>`_)
-* Documentation and websites for all the above (e.g. `python.org repository <https://github.com/python/pythondotorg>`_, `PEPs <https://github.com/python/peps>`_, `Devguide <https://github.com/python/devguide>`_, docs translations)
-* Infrastructure for all the above (e.g. `docsbuild-scripts <https://github.com/python/docsbuild-scripts>`_, `buildmaster-config <https://github.com/python/buildmaster-config>`_)
-* Discussions and notes around official development-related processes and events (e.g. `steering-council <https://github.com/python/steering-council>`_, `core-sprint <https://github.com/python/core-sprint>`_)
+* The reference implementation of Python and related repositories: `CPython <https://github.com/python/cpython>`_.
+* Tooling and support around CPython development: `pyperformance <https://github.com/python/pyperformance>`_, `Bedevere <https://github.com/python/bedevere>`_.
+* Helpers and backports for Python/CPython features: `typing_extensions <https://github.com/python/typing_extensions>`_, `typeshed <https://github.com/python/typeshed>`_, `tzdata <https://github.com/python/tzdata>`_, `pythoncapi-compat <https://github.com/python/pythoncapi-compat>`_.
+* Organization-related repositories: the `Code of Conduct <https://github.com/python/pycon-code-of-conduct>`_, `.github <https://github.com/python/.github>`_.
+* Documentation and websites for all the above: `python.org repository <https://github.com/python/pythondotorg>`_, `PEPs <https://github.com/python/peps>`_, `Devguide <https://github.com/python/devguide>`_, docs translations.
+* Infrastructure for all the above: `docsbuild-scripts <https://github.com/python/docsbuild-scripts>`_, `buildmaster-config <https://github.com/python/buildmaster-config>`_.
+* Discussions and notes around official development-related processes and events: `steering-council <https://github.com/python/steering-council>`_, `core-sprint <https://github.com/python/core-sprint>`_.
 
 Before adding a new repository to the organization, open a discussion to seek consensus
 in the `Committers Discourse category <https://discuss.python.org/c/committers/5>`_.
@@ -248,13 +248,13 @@ accounts or other GitHub orgs. It is relatively easy to move a repository to
 the organization once it is mature. For example, this would now apply to
 experimental features like `asyncio <https://github.com/python/asyncio>`_,
 `exceptiongroups <https://github.com/python/exceptiongroups>`_,
-and drafts of new guides and other documentation (e.g. `redistributor-guide
+and drafts of new guides and other documentation (for example, `redistributor-guide
 <https://github.com/python/redistributor-guide>`_).
 
-General-use tools and libraries (e.g. `mypy <https://github.com/python/mypy>`_
+General-use tools and libraries (for example, `mypy <https://github.com/python/mypy>`_
 or `Black <https://github.com/psf/black>`_) should also be developed outside
 the ``python`` organization, unless core devs (as represented by the SC)
-specifically want to “bless” one implementation (as with e.g.
+specifically want to “bless” one implementation (as with
 `typeshed <https://github.com/python/typeshed>`_,
 `tzdata <https://github.com/python/tzdata>`_, or
 `pythoncapi-compat <https://github.com/python/pythoncapi-compat>`_).

developer-workflow/porting.rst

@@ -13,11 +13,11 @@ which it has already been ported; preferably Unix, but Windows will
 do, too. The build process for Python, in particular the ``Makefile`` in the
 source distribution, will give you a hint on which files to compile
 for Python.  Not all source files are relevant: some are platform-specific,
-and others are only used in emergencies (e.g. ``getopt.c``).
+and others are only used in emergencies (for example, ``getopt.c``).
 
 It is not recommended to start porting Python without at least a medium-level
-understanding of your target platform; i.e. how it is generally used, how to
-write platform-specific apps, etc. Also, some Python knowledge is required, or
+understanding of your target platform; how it is generally used, how to
+write platform-specific apps, and so on. Also, some Python knowledge is required, or
 you will be unable to verify that your port is working correctly.
 
 You will need a ``pyconfig.h`` file tailored for your platform.  You can

developer-workflow/stdlib.rst

@@ -108,7 +108,7 @@ year, a module needs to have established itself as (one of) the top choices by
 the community for solving the problem the module is intended for.
 
 The development of the module must move into Python's
-infrastructure (i.e., the module is no longer directly maintained outside of
+infrastructure (that is, the module is no longer directly maintained outside of
 Python). This prevents a divergence between the code that is included in the
 stdlib and that which is released outside the stdlib (typically done to provide
 the module to older versions of Python). It also removes the burden of forcing

development-tools/clinic.rst

@@ -213,7 +213,7 @@ Classes for extending Argument Clinic
 
       The C type to use for this variable.
       :attr:`!type` should be a Python string specifying the type,
-      e.g. ``'int'``.
+      for example, ``'int'``.
       If this is a pointer type, the type string should end with ``' *'``.
 
    .. attribute:: default

development-tools/gdb.rst

@@ -33,7 +33,7 @@ Fortunately, among the `many ways to set breakpoints
 you can break at C labels, such as those generated for computed gotos.
 If you are debugging an interpreter compiled with computed goto support
 (generally true, certainly when using GCC), each instruction will be
-prefaced with a label named ``TARGET_<instruction>``, e.g.,
+prefaced with a label named ``TARGET_<instruction>``, for example,
 ``TARGET_LOAD_CONST``.  You can then set a breakpoint with a command
 like::
 

documentation/help-documenting.rst

@@ -74,7 +74,7 @@ Proofreading
 While an issue filed on the `issue tracker`_ means there is a known issue
 somewhere, that does not mean there are not other issues lurking about in the
 documentation. Proofreading a part of the documentation, such as a "How to" or
-OS specific document, can often uncover problems (e.g., documentation that
+OS specific document, can often uncover problems (for example, documentation that
 needs updating for Python 3).
 
 If you decide to proofread, read a section of the documentation from start