docs: get rid of e.g./i.e.

Author: hynek

CHANGELOG.md

@@ -124,7 +124,7 @@ You can find our backwards-compatibility policy [here](https://github.com/hynek/
 
 ### Deprecated
 
-- Accessing package metadata as attributes on the *structlog* module is deprecated (e.g. `structlog.__version__`).
+- Accessing package metadata as attributes on the *structlog* module is deprecated (for example, `structlog.__version__`).
   Please use [`importlib.metadata`](https://docs.python.org/3.10/library/importlib.metadata.html) instead (for Python 3.7: the [*importlib-metadata*](https://pypi.org/project/importlib-metadata/) PyPI package).
 - The `structlog.types` module is now deprecated in favor of the `structlog.typing` module.
   It seems like the Python typing community is settling on this name.
@@ -277,7 +277,7 @@ You can find our backwards-compatibility policy [here](https://github.com/hynek/
 - *structlog* switched its packaging to [*flit*](https://flit.pypa.io/).
   Users shouldn't notice a difference, but (re-)packagers might.
 - `structlog.stdlib.AsyncBoundLogger` now determines the running loop when logging, not on instantiation.
-  That has a minor performance impact, but makes it more robust when loops change (e.g. `aiohttp.web.run_app()`), or you want to use `sync_bl` *before* a loop has started.
+  That has a minor performance impact, but makes it more robust when loops change (for example, `aiohttp.web.run_app()`), or you want to use `sync_bl` *before* a loop has started.
 
 
 ### Fixed
@@ -331,7 +331,7 @@ You can find our backwards-compatibility policy [here](https://github.com/hynek/
 
 ### Fixed
 
-- *structlog* is now importable if `sys.stdout` is `None` (e.g. when running using `pythonw`). [#313](https://github.com/hynek/structlog/issues/313)
+- *structlog* is now importable if `sys.stdout` is `None` (for example, when running using `pythonw`). [#313](https://github.com/hynek/structlog/issues/313)
 
 
 ## [21.1.0](https://github.com/hynek/structlog/compare/20.2.0...21.1.0) - 2021-02-18
@@ -372,7 +372,7 @@ You can find our backwards-compatibility policy [here](https://github.com/hynek/
 - *structlog* has now type hints for all of its APIs!
   Since *structlog* is highly dynamic and configurable, this led to a few concessions like a specialized `structlog.stdlib.get_logger()` whose only difference to `structlog.get_logger()` is that it has the correct type hints.
 
-  We consider them provisional for the time being – i.e. the backwards-compatibility does not apply to them in its full strength until we feel we got it right.
+  We consider them provisional for the time being – that means the backwards-compatibility does not apply to them in its full strength until we feel we got it right.
   Please feel free to provide feedback!
   [#223](https://github.com/hynek/structlog/issues/223),
   [#282](https://github.com/hynek/structlog/issues/282)
@@ -788,7 +788,7 @@ Special thanks go to [Fabian Büchler](https://github.com/fabianbuechler), [Gilb
 - Add `structlog.processors.ExceptionPrettyPrinter` for development and testing when multiline log entries aren't just acceptable but even helpful.
 - Allow the standard library name guesser to ignore certain frame names.
   This is useful together with frameworks.
-- Add meta data (e.g. function names, line numbers) extraction for wrapped stdlib loggers. [#5](https://github.com/hynek/structlog/pull/5)
+- Add meta data (for example, function names, line numbers) extraction for wrapped stdlib loggers. [#5](https://github.com/hynek/structlog/pull/5)
 
 
 ## [0.3.2](https://github.com/hynek/structlog/compare/0.3.1...0.3.2) - 2013-09-27

docs/bound-loggers.md

@@ -153,7 +153,7 @@ You will configure *structlog* as explained in the {doc}`next chapter <configura
 
 However, in some rare cases you may not want to do that.
 For example because you don't control how you get the logger that you would like to wrap (famous example: Celery).
-For that times there is the {func}`structlog.wrap_logger` function that can be used to wrap a logger -- optionally without any global state (i.e. configuration):
+For that times there is the {func}`structlog.wrap_logger` function that can be used to wrap a logger -- optionally without any global state (in other words, configuration):
 
 (proc)=
 

docs/contextvars.md

@@ -85,7 +85,7 @@ event='hi there' a=None
 
 ## Support for `contextvars.Token`
 
-If e.g. your request handler calls a helper function that needs to temporarily override some contextvars before restoring them back to their original values, you can use the {class}`~contextvars.Token`s returned by {func}`~structlog.contextvars.bind_contextvars` along with {func}`~structlog.contextvars.reset_contextvars` to accomplish this (much like how {meth}`contextvars.ContextVar.reset` works):
+If, for example, your request handler calls a helper function that needs to temporarily override some contextvars before restoring them back to their original values, you can use the {class}`~contextvars.Token`s returned by {func}`~structlog.contextvars.bind_contextvars` along with {func}`~structlog.contextvars.reset_contextvars` to accomplish this (much like how {meth}`contextvars.ContextVar.reset` works):
 
 ```python
 def foo():

docs/processors.md

@@ -1,7 +1,8 @@
 # Processors
 
 The true power of *structlog* lies in its *combinable log processors*.
-A log processor is a regular callable, i.e. a function or an instance of a class with a `__call__()` method.
+A log processor is a regular callable or in other words:
+A function or an instance of a class with a `__call__()` method.
 
 (chains)=
 
@@ -29,7 +30,7 @@ The return value of each processor is passed on to the next one as `event_dict`
 
 :::{note}
 *structlog* only looks at the return value of the **last** processor.
-That means that as long as you control the next processor in the chain (i.e. the processor that will get your return value passed as an argument), you can return whatever you want.
+That means that as long as you control the next processor in the chain (the processor that will get your return value passed as an argument), you can return whatever you want.
 
 Returning a modified event dictionary from your processors is just a convention to make processors composable.
 :::
@@ -95,7 +96,7 @@ But we can do better than that!
 
 (cond-drop)=
 
-How about dropping only log entries that are marked as coming from a certain peer (e.g. monitoring)?
+How about dropping only log entries that are marked as coming from a certain peer (for example, monitoring)?
 
 ```python
 class ConditionalDropper:

docs/standard-library.md

@@ -30,7 +30,7 @@ logging.basicConfig(
 )
 ```
 
-This will send all log messages with the [log level](https://docs.python.org/3/library/logging.html#logging-levels) `logging.INFO` and above (that means that e.g. `logging.debug` calls are ignored) to standard out without any special formatting by the standard library.
+This will send all log messages with the [log level](https://docs.python.org/3/library/logging.html#logging-levels) `logging.INFO` and above (that means that, for example, `logging.debug` calls are ignored) to standard out without any special formatting by the standard library.
 
 If you require more complex behavior, please refer to the standard library's `logging` documentation.
 
@@ -63,13 +63,14 @@ This means an increased computational cost per log entry, but your application w
 ---
 
 
-*structlog* also comes with {class}`structlog.stdlib.AsyncBoundLogger` that blankly makes all logging methods asynchronous (i.e. `await log.info()`).
+*structlog* also comes with {class}`structlog.stdlib.AsyncBoundLogger` that blankly makes all logging methods asynchronous (in other words, you have to use `await log.info()` instead of just `log.info()`).
 
 To use it, {doc}`configure <configuration>` *structlog* to use `AsyncBoundLogger` as `wrapper_class`.
 
 ```{versionadded} 20.2.0
 ```
-
+```{deprecated} 23.1.0
+```
 
 
 ## Processors
@@ -118,7 +119,7 @@ To use it, {doc}`configure <configuration>` *structlog* to use `AsyncBoundLogger
 
 {func}`~structlog.stdlib.PositionalArgumentsFormatter`:
 
-: This processes and formats positional arguments (if any) passed to log methods in the same way the `logging` module would do, e.g. `logger.info("Hello, %s", name)`.
+: This processes and formats positional arguments (if any) passed to log methods in the same way the `logging` module would do, for example, `logger.info("Hello, %s", name)`.
 
 *structlog* also comes with {class}`~structlog.stdlib.ProcessorFormatter` which is a `logging.Formatter` that enables you to format non-*structlog* log entries using *structlog* renderers *and* multiplex *structlog*’s output with different renderers (see [below](processor-formatter) for an example).
 
@@ -285,7 +286,7 @@ structlog.configure(
 ```
 
 Now you have the event dict available within each log record.
-If you want all your log entries (i.e. also those not from your application / *structlog*) to be formatted as JSON, you can use the [*python-json-logger*] library:
+If you want *all* your log entries (meaning: also those not from your application / *structlog*) to be formatted as JSON, you can use the [*python-json-logger*] library:
 
 ```python
 import logging
@@ -393,7 +394,7 @@ amazing  _from_structlog=True _record=<LogRecord:...> events=oh yes
 ```
 
 Of course, you probably want timestamps and log levels in your output.
-The `ProcessorFormatter` has a `foreign_pre_chain` argument which is responsible for adding properties to events from the standard library -- i.e. that do not originate from a *structlog* logger -- and which should in general match the `processors` argument to {func}`structlog.configure` so you get a consistent output.
+The `ProcessorFormatter` has a `foreign_pre_chain` argument which is responsible for adding properties to events from the standard library -- in other words, those that do not originate from a *structlog* logger -- and which should in general match the `processors` argument to {func}`structlog.configure` so you get a consistent output.
 
 `_from_structlog` and `_record` allow your processors to determine whether the log entry is coming from *structlog*, and to extract information from `logging.LogRecord`s and add them to the event dictionary.
 However, you probably don't want to have them in your log files, thus we've added the `ProcessorFormatter.remove_processors_meta` processor to do so conveniently.

docs/why.md

@@ -53,7 +53,7 @@ Since log entries are dictionaries, you can start binding and re-binding key-val
 2020-11-18 09:18:28 [info     ] user.logged_in    another_key=42 happy=True some_key=23 user=hynek
 ```
 
-You can also bind key-value pairs to {doc}`context variables <contextvars>` that look global, but are local to your thread or *asyncio* context (i.e. usually your request).
+You can also bind key-value pairs to {doc}`context variables <contextvars>` that look global, but are local to your thread or *asyncio* context -- which usually means your web request.
 
 
 ### Powerful Pipelines

src/structlog/stdlib.py

@@ -1113,11 +1113,12 @@ def wrap_for_formatter(
         """
         Wrap *logger*, *name*, and *event_dict*.
 
-        The result is later unpacked by `ProcessorFormatter` when
-        formatting log entries.
+        The result is later unpacked by `ProcessorFormatter` when formatting
+        log entries.
 
-        Use this static method as the renderer (i.e. final processor) if you
-        want to use `ProcessorFormatter` in your `logging` configuration.
+        Use this static method as the renderer (in other words, final
+        processor) if you want to use `ProcessorFormatter` in your `logging`
+        configuration.
         """
         return (event_dict,), {"extra": {"_logger": logger, "_name": name}}