From 69203d21de44ee8557e065eb308b54d355ab539f Mon Sep 17 00:00:00 2001 From: "google-labs-jules[bot]" <161369871+google-labs-jules[bot]@users.noreply.github.com> Date: Thu, 26 Jun 2025 09:40:49 +0000 Subject: [PATCH 1/3] Add STYLE_GUIDE.md to docs and enhance content This commit introduces STYLE_GUIDE.md in the docs/ directory to outline coding conventions, patterns, and best practices for the project. Key changes from any previous (uncommitted) versions: - Moved the style guide to `docs/STYLE_GUIDE.md`. - Added a dedicated 'Testing' section with expanded guidelines on: - Test location and naming. - Use of Pytest fixtures (e.g., `LoggingEnvironment` pattern). - Test parametrization. - Writing clear, focused, and robust test cases. - Clarified Markdown heading usage versus internal code comment sectioning. The guide covers: - Use of automated formatters/linters (Black, Pylint, MyPy). - Import organization. - Naming conventions. - Type hinting requirements. - Docstring standards (Google style via mkdocstrings) with version markers. - Rule for explicit return statements. - Class structure and internal code commenting conventions. - Common code patterns (versioning, TypeAlias, custom exceptions, utils). --- docs/STYLE_GUIDE.md | 146 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 docs/STYLE_GUIDE.md diff --git a/docs/STYLE_GUIDE.md b/docs/STYLE_GUIDE.md new file mode 100644 index 0000000..71e4d86 --- /dev/null +++ b/docs/STYLE_GUIDE.md @@ -0,0 +1,146 @@ +# Python Style Guide + +This document outlines the coding style, conventions, and common patterns for the `python-json-logger` project. Adhering to this guide will help maintain code consistency, readability, and quality. + +## General Principles + +* **Readability Counts:** Write code that is easy for others (and your future self) to understand. +* **Consistency:** Strive for consistency in naming, formatting, and structure throughout the codebase. +* **Simplicity:** Prefer simple, straightforward solutions over overly complex ones. + +## Formatting and Linting + +We use automated tools to enforce a consistent code style and catch potential errors. These include: + +* **Black:** For opinionated code formatting. +* **Pylint:** For static code analysis and error detection. +* **MyPy:** For static type checking. + +Ensure these tools are run before committing code. Configuration for these tools can be found in `pyproject.toml`, `pylintrc`, and `mypy.ini` respectively. This guide does not repeat rules enforced by these tools but focuses on conventions not automatically verifiable. + +## Imports + +Imports should be structured into the following groups, separated by a blank line: + +1. **Future Imports:** e.g., `from __future__ import annotations` +2. **Standard Library Imports:** e.g., `import sys`, `from datetime import datetime` +3. **Installed (Third-Party) Library Imports:** e.g., `import pytest` +4. **Application (Local) Imports:** e.g., `from .core import BaseJsonFormatter` + +Within each group, imports should generally be alphabetized. + +## Naming Conventions + +* **Modules:** `lowercase_with_underscores.py` +* **Packages:** `lowercase` +* **Classes:** `CapWords` (e.g., `BaseJsonFormatter`) +* **Type Aliases:** `CapWords` (e.g., `OptionalCallableOrStr`) +* **Functions and Methods:** `lowercase_with_underscores()` (e.g., `merge_record_extra()`) +* **Variables:** `lowercase_with_underscores` +* **Constants:** `UPPERCASE_WITH_UNDERSCORES` (e.g., `RESERVED_ATTRS`) + +## Type Hinting + +* All new code **must** include type hints for function arguments, return types, and variables where appropriate. +* Use standard types from the `typing` module (e.g., `Optional`, `Union`, `List`, `Dict`, `Callable`, `Any`). +* For Python versions older than 3.10, use `typing_extensions.TypeAlias` for creating type aliases. For Python 3.10+, use `typing.TypeAlias`. + +## Docstrings + +* All public modules, classes, functions, and methods **must** have docstrings. +* We use `mkdocstrings` for generating API documentation, which defaults to the **Google Python Style Guide** for docstrings. Please adhere to this style. You can find the guide [here](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings). +* Docstrings should clearly explain the purpose, arguments, return values, and any exceptions raised. +* Use the following markers to indicate changes over time: + * `*New in version_number*`: For features added in a specific version. + * `*Changed in version_number*`: For changes made in a specific version. + * `*Deprecated in version_number*`: For features deprecated in a specific version. + + Example: + ```python + def my_function(param1: str, param2: int) -> bool: + """Does something interesting. + + Args: + param1: The first parameter, a string. + param2: The second parameter, an integer. + + Returns: + True if successful, False otherwise. + + Raises: + ValueError: If param2 is negative. + + *New in 3.1* + """ + if param2 < 0: + raise ValueError("param2 cannot be negative") + # ... function logic ... + return True + ``` + +## Return Statements + +* **All functions and methods must have an explicit `return` statement.** +* If a function does not logically return a value, it should end with `return None` or simply `return`. This makes the intent clear. + + Example: + ```python + def process_data(data: dict) -> None: + """Processes the given data.""" + # ... processing logic ... + print(data) + return # or return None + ``` + +## Class Structure + +* Group methods logically within a class. For example: + * Initialization methods (`__init__`, `__new__`) + * Public methods + * Protected/Private methods (by convention, prefixed with `_` or `__`) + * Special methods (`__str__`, `__repr__`) +* Within source code comments, use `## Section Name ##` or `### Subsection Name ###` to delineate logical sections if it improves readability, especially in larger classes (e.g., `## Parent Methods ##` as seen in `src/pythonjsonlogger/core.py`). + +## Testing + +This project uses `pytest` for testing. + +* **Test Location:** Tests are located in the `tests/` directory. +* **Test Naming:** Test files should be named `test_*.py` and test functions/methods should be prefixed with `test_`. +* **Fixtures:** Utilize `pytest` fixtures (e.g., `@pytest.fixture`) for setting up test preconditions and managing test state. + * The `LoggingEnvironment` dataclass and `env` fixture in `tests/test_formatters.py` are good examples of reusable test setups for logger testing. Strive to create similar helpers for common testing scenarios. +* **Parametrization:** Use `@pytest.mark.parametrize` to run the same test function with different inputs and expected outputs. This is highly encouraged to reduce code duplication and cover multiple scenarios efficiently. +* **Clarity and Focus:** Each test case should ideally test one specific aspect of functionality. Test names should be descriptive of what they are testing. +* **Assertions:** Use clear and specific `pytest` assertions (e.g., `assert foo == bar`, `assert isinstance(obj, MyClass)`). +* **Robustness:** Write tests that are not overly brittle. For example, avoid making assertions on exact string matches of complex, auto-generated outputs if only a part of it is relevant. + +## Common Code Patterns and Idioms + +* **Version-Specific Logic:** When code needs to behave differently based on the Python version, use `sys.version_info`: + ```python + if sys.version_info >= (3, 10): + # Python 3.10+ specific code + pass + else: + # Code for older versions + pass + ``` +* **Type Aliases for Clarity:** Use `TypeAlias` for complex or frequently used type combinations to improve readability. + ```python + from typing import List, Tuple, Union + from typing_extensions import TypeAlias # For Python < 3.10 + + Coordinate: TypeAlias = Tuple[int, int] + PointOrListOfPoints: TypeAlias = Union[Coordinate, List[Coordinate]] + ``` +* **Custom Exceptions:** Define custom exception classes for application-specific error conditions to provide more meaningful error information (e.g., `MissingPackageError`). +* **Helper/Utility Functions:** Encapsulate reusable logic into well-named helper functions, often placed in `utils.py` or similar utility modules. + +## Comments + +* Use comments to explain non-obvious code, complex logic, or important decisions. +* Avoid comments that merely restate what the code does. +* Module-level, class-level, and function/method-level explanations should primarily be in docstrings. +* For internal code organization within files, especially in longer modules or classes, use comments like `## Section Title ##` or `### Subsection Title ###` to delineate logical blocks of code. This is distinct from Markdown headings used in this document. + +By following these guidelines, we can ensure that `python-json-logger` remains a high-quality, maintainable, and developer-friendly library. From cebc4b472b65e662705b93aa4c092aa9b6c375a4 Mon Sep 17 00:00:00 2001 From: "google-labs-jules[bot]" <161369871+google-labs-jules[bot]@users.noreply.github.com> Date: Thu, 26 Jun 2025 10:36:10 +0000 Subject: [PATCH 2/3] Refine and relocate style guide, update contributing docs This commit implements several improvements to the project's style guide and its integration into the contribution process: 1. **Style Guide Content and Structure (`docs/style-guide.md`):** * Reordered sections for better logical flow. * Added references to PEP 8 and PEP 20 (Zen of Python) under 'General Principles'. * Refined rules to differentiate between general Python best practices and project-specific conventions (e.g., import grouping, `TypeAlias` usage, explicit returns, version markers in docstrings, `LoggingEnvironment` test pattern). * Removed some overly common Python rules to reduce verbosity. * Clarified naming for 'Project-Specific Code Patterns and Idioms' and added the conditional import pattern. 2. **File Renaming:** * Renamed `docs/STYLE_GUIDE.md` to `docs/style-guide.md` to match the naming convention of other documentation files. 3. **Contributing Guide Update (`docs/contributing.md`):** * Added a new 'Coding Style' subsection under 'Fork the repository and make your changes'. * This new subsection explicitly directs contributors to read and adhere to the `docs/style-guide.md`. --- docs/STYLE_GUIDE.md | 146 ------------------------------------------- docs/contributing.md | 8 ++- docs/quickstart.md | 2 +- docs/style-guide.md | 131 ++++++++++++++++++++++++++++++++++++++ 4 files changed, 139 insertions(+), 148 deletions(-) delete mode 100644 docs/STYLE_GUIDE.md create mode 100644 docs/style-guide.md diff --git a/docs/STYLE_GUIDE.md b/docs/STYLE_GUIDE.md deleted file mode 100644 index 71e4d86..0000000 --- a/docs/STYLE_GUIDE.md +++ /dev/null @@ -1,146 +0,0 @@ -# Python Style Guide - -This document outlines the coding style, conventions, and common patterns for the `python-json-logger` project. Adhering to this guide will help maintain code consistency, readability, and quality. - -## General Principles - -* **Readability Counts:** Write code that is easy for others (and your future self) to understand. -* **Consistency:** Strive for consistency in naming, formatting, and structure throughout the codebase. -* **Simplicity:** Prefer simple, straightforward solutions over overly complex ones. - -## Formatting and Linting - -We use automated tools to enforce a consistent code style and catch potential errors. These include: - -* **Black:** For opinionated code formatting. -* **Pylint:** For static code analysis and error detection. -* **MyPy:** For static type checking. - -Ensure these tools are run before committing code. Configuration for these tools can be found in `pyproject.toml`, `pylintrc`, and `mypy.ini` respectively. This guide does not repeat rules enforced by these tools but focuses on conventions not automatically verifiable. - -## Imports - -Imports should be structured into the following groups, separated by a blank line: - -1. **Future Imports:** e.g., `from __future__ import annotations` -2. **Standard Library Imports:** e.g., `import sys`, `from datetime import datetime` -3. **Installed (Third-Party) Library Imports:** e.g., `import pytest` -4. **Application (Local) Imports:** e.g., `from .core import BaseJsonFormatter` - -Within each group, imports should generally be alphabetized. - -## Naming Conventions - -* **Modules:** `lowercase_with_underscores.py` -* **Packages:** `lowercase` -* **Classes:** `CapWords` (e.g., `BaseJsonFormatter`) -* **Type Aliases:** `CapWords` (e.g., `OptionalCallableOrStr`) -* **Functions and Methods:** `lowercase_with_underscores()` (e.g., `merge_record_extra()`) -* **Variables:** `lowercase_with_underscores` -* **Constants:** `UPPERCASE_WITH_UNDERSCORES` (e.g., `RESERVED_ATTRS`) - -## Type Hinting - -* All new code **must** include type hints for function arguments, return types, and variables where appropriate. -* Use standard types from the `typing` module (e.g., `Optional`, `Union`, `List`, `Dict`, `Callable`, `Any`). -* For Python versions older than 3.10, use `typing_extensions.TypeAlias` for creating type aliases. For Python 3.10+, use `typing.TypeAlias`. - -## Docstrings - -* All public modules, classes, functions, and methods **must** have docstrings. -* We use `mkdocstrings` for generating API documentation, which defaults to the **Google Python Style Guide** for docstrings. Please adhere to this style. You can find the guide [here](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings). -* Docstrings should clearly explain the purpose, arguments, return values, and any exceptions raised. -* Use the following markers to indicate changes over time: - * `*New in version_number*`: For features added in a specific version. - * `*Changed in version_number*`: For changes made in a specific version. - * `*Deprecated in version_number*`: For features deprecated in a specific version. - - Example: - ```python - def my_function(param1: str, param2: int) -> bool: - """Does something interesting. - - Args: - param1: The first parameter, a string. - param2: The second parameter, an integer. - - Returns: - True if successful, False otherwise. - - Raises: - ValueError: If param2 is negative. - - *New in 3.1* - """ - if param2 < 0: - raise ValueError("param2 cannot be negative") - # ... function logic ... - return True - ``` - -## Return Statements - -* **All functions and methods must have an explicit `return` statement.** -* If a function does not logically return a value, it should end with `return None` or simply `return`. This makes the intent clear. - - Example: - ```python - def process_data(data: dict) -> None: - """Processes the given data.""" - # ... processing logic ... - print(data) - return # or return None - ``` - -## Class Structure - -* Group methods logically within a class. For example: - * Initialization methods (`__init__`, `__new__`) - * Public methods - * Protected/Private methods (by convention, prefixed with `_` or `__`) - * Special methods (`__str__`, `__repr__`) -* Within source code comments, use `## Section Name ##` or `### Subsection Name ###` to delineate logical sections if it improves readability, especially in larger classes (e.g., `## Parent Methods ##` as seen in `src/pythonjsonlogger/core.py`). - -## Testing - -This project uses `pytest` for testing. - -* **Test Location:** Tests are located in the `tests/` directory. -* **Test Naming:** Test files should be named `test_*.py` and test functions/methods should be prefixed with `test_`. -* **Fixtures:** Utilize `pytest` fixtures (e.g., `@pytest.fixture`) for setting up test preconditions and managing test state. - * The `LoggingEnvironment` dataclass and `env` fixture in `tests/test_formatters.py` are good examples of reusable test setups for logger testing. Strive to create similar helpers for common testing scenarios. -* **Parametrization:** Use `@pytest.mark.parametrize` to run the same test function with different inputs and expected outputs. This is highly encouraged to reduce code duplication and cover multiple scenarios efficiently. -* **Clarity and Focus:** Each test case should ideally test one specific aspect of functionality. Test names should be descriptive of what they are testing. -* **Assertions:** Use clear and specific `pytest` assertions (e.g., `assert foo == bar`, `assert isinstance(obj, MyClass)`). -* **Robustness:** Write tests that are not overly brittle. For example, avoid making assertions on exact string matches of complex, auto-generated outputs if only a part of it is relevant. - -## Common Code Patterns and Idioms - -* **Version-Specific Logic:** When code needs to behave differently based on the Python version, use `sys.version_info`: - ```python - if sys.version_info >= (3, 10): - # Python 3.10+ specific code - pass - else: - # Code for older versions - pass - ``` -* **Type Aliases for Clarity:** Use `TypeAlias` for complex or frequently used type combinations to improve readability. - ```python - from typing import List, Tuple, Union - from typing_extensions import TypeAlias # For Python < 3.10 - - Coordinate: TypeAlias = Tuple[int, int] - PointOrListOfPoints: TypeAlias = Union[Coordinate, List[Coordinate]] - ``` -* **Custom Exceptions:** Define custom exception classes for application-specific error conditions to provide more meaningful error information (e.g., `MissingPackageError`). -* **Helper/Utility Functions:** Encapsulate reusable logic into well-named helper functions, often placed in `utils.py` or similar utility modules. - -## Comments - -* Use comments to explain non-obvious code, complex logic, or important decisions. -* Avoid comments that merely restate what the code does. -* Module-level, class-level, and function/method-level explanations should primarily be in docstrings. -* For internal code organization within files, especially in longer modules or classes, use comments like `## Section Title ##` or `### Subsection Title ###` to delineate logical blocks of code. This is distinct from Markdown headings used in this document. - -By following these guidelines, we can ensure that `python-json-logger` remains a high-quality, maintainable, and developer-friendly library. diff --git a/docs/contributing.md b/docs/contributing.md index 61ed3e0..9135625 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -25,7 +25,13 @@ The following are things that can be worked on without an existing issue: ### 2. Fork the repository and make your changes -We don't have styling documentation, so where possible try to match existing code. This includes the use of "headings" and "dividers" (this will make sense when you look at the code). +#### Coding Style + +Before writing any code, please familiarize yourself with our [Python Style Guide](style-guide.md). This document outlines our coding conventions, formatting expectations, and common patterns used in the project. Adhering to this guide is crucial for maintaining code consistency and readability. + +While the style guide covers detailed conventions, always try to match the style of existing code in the module you are working on, especially regarding local patterns and structure. + +#### Development Setup All devlopment tooling can be installed (usually into a virtual environment), using the `dev` optional dependency: diff --git a/docs/quickstart.md b/docs/quickstart.md index 07486b1..7dab254 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -104,7 +104,7 @@ formatter = JsonFormatter( ### Excluding fields -You can prevent fields being added to the output data by adding them to `reserved_attrs`. By default all [`LogRecord` attributes](https://docs.python.org/3/library/logging.html#logrecord-attributes) are excluded. +You can prevent fields being added to the output data by adding them to `reserved_attrs`. By default all [`LogRecord` attributes](https://docs.python.org/3/library/logging.html#logrecord-attributes) are exluded. ```python from pythonjsonlogger.core import RESERVED_ATTRS diff --git a/docs/style-guide.md b/docs/style-guide.md new file mode 100644 index 0000000..ab217c5 --- /dev/null +++ b/docs/style-guide.md @@ -0,0 +1,131 @@ +# Python Style Guide + +This document outlines the coding style, conventions, and common patterns for the `python-json-logger` project. Adhering to this guide will help maintain code consistency, readability, and quality. + +## General Principles + +* **Readability Counts:** Write code that is easy for others (and your future self) to understand. This aligns with [PEP 20 (The Zen of Python)](https://peps.python.org/pep-0020/). +* **Consistency:** Strive for consistency in naming, formatting, and structure throughout the codebase. +* **Simplicity:** Prefer simple, straightforward solutions over overly complex ones. +* **PEP 8:** Follow [PEP 8 (Style Guide for Python Code)](https://peps.python.org/pep-0008/) for all Python code. The automated tools mentioned below will enforce many of these rules. This guide highlights project-specific conventions or particularly important PEP 8 aspects. + +## Formatting and Linting + +We use automated tools to enforce a consistent code style and catch potential errors. These include: + +* **Black:** For opinionated code formatting. +* **Pylint:** For static code analysis and error detection. +* **MyPy:** For static type checking. + +Ensure these tools are run before committing code. Configuration for these tools can be found in `pyproject.toml`, `pylintrc`, and `mypy.ini` respectively. This guide primarily focuses on conventions not automatically verifiable by these tools. + +## Imports + +Imports should be structured into the following groups, separated by a blank line, and generally alphabetized within each group: + +1. **Future Imports:** e.g., `from __future__ import annotations` +2. **Standard Library Imports:** e.g., `import sys`, `from datetime import datetime` +3. **Installed (Third-Party) Library Imports:** e.g., `import pytest` +4. **Application (Local) Imports:** e.g., `from .core import BaseJsonFormatter` (This project-specific pattern is crucial for internal organization). + +## Naming Conventions + +While PEP 8 covers most naming, we emphasize: + +* **Modules:** `lowercase_with_underscores.py` +* **Packages:** `lowercase` +* **Classes & Type Aliases:** `CapWords` (e.g., `BaseJsonFormatter`, `OptionalCallableOrStr`). This is standard, but explicitly stated for clarity. +* **Constants:** `UPPERCASE_WITH_UNDERSCORES` (e.g., `RESERVED_ATTRS`). This is a project convention for module-level constants. + +(Functions, methods, and variables follow standard PEP 8 `lowercase_with_underscores`). + +## Comments + +* Use comments to explain non-obvious code, complex logic, or important design decisions. Avoid comments that merely restate what the code does. +* For internal code organization within files, especially in longer modules or classes, use comments like `## Section Title ##` or `### Subsection Title ###` to delineate logical blocks of code (e.g., `## Parent Methods ##` as seen in `src/pythonjsonlogger/core.py`). This is distinct from Markdown headings used in this document. + +## Docstrings + +* All public modules, classes, functions, and methods **must** have docstrings. +* We use `mkdocstrings` for generating API documentation, which defaults to the **Google Python Style Guide** for docstrings. Please adhere to this style. You can find the guide [here](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings). +* Docstrings should clearly explain the purpose, arguments, return values, and any exceptions raised. +* **Project Convention:** Use the following markers to indicate changes over time: + * `*New in version_number*`: For features added in a specific version. + * `*Changed in version_number*`: For changes made in a specific version. + * `*Deprecated in version_number*`: For features deprecated in a specific version. + + Example: + ```python + def my_function(param1: str, param2: int) -> bool: + """Does something interesting. + + Args: + param1: The first parameter, a string. + param2: The second parameter, an integer. + + Returns: + True if successful, False otherwise. + + Raises: + ValueError: If param2 is negative. + + *New in 3.1* + """ + # ... function logic ... + return True # See 'Return Statements' + ``` + +## Type Hinting + +* All new code **must** include type hints for function arguments, return types, and variables where appropriate, as per PEP 484. +* Use standard types from the `typing` module. +* **Project Convention:** For Python versions older than 3.10, use `typing_extensions.TypeAlias` for creating type aliases. For Python 3.10+, use `typing.TypeAlias` (e.g., `OptionalCallableOrStr: TypeAlias = ...`). + +## Return Statements + +* **Project Convention:** All functions and methods **must** have an explicit `return` statement. +* If a function does not logically return a value, it should end with `return None` or simply `return`. This makes the intent clear and consistent across the codebase. + + Example: + ```python + def process_data(data: dict) -> None: + """Processes the given data.""" + # ... processing logic ... + print(data) + return # or return None + ``` + +## Class Structure + +* Group methods logically within a class (e.g., initialization, public, protected/private, special methods). +* The use of internal code comments like `## Parent Methods ##` (as seen in `src/pythonjsonlogger/core.py`) is encouraged for readability in complex classes. + +## Project-Specific Code Patterns and Idioms + +Familiarize yourself with these patterns commonly used in this project: + +* **Version-Specific Logic:** Using `sys.version_info` for compatibility: + ```python + if sys.version_info >= (3, 10): + # Python 3.10+ specific code + else: + # Code for older versions + ``` +* **Type Aliases for Clarity:** As mentioned in Type Hinting, using `TypeAlias` for complex type combinations improves readability. +* **Custom Exceptions:** Defining custom exception classes for application-specific error conditions (e.g., `MissingPackageError` in `src/pythonjsonlogger/exception.py`). +* **Helper/Utility Functions:** Encapsulating reusable logic in utility modules (e.g., functions in `src/pythonjsonlogger/utils.py`). +* **Conditional Imports for Optional Dependencies:** The pattern in `src/pythonjsonlogger/__init__.py` for checking optional dependencies like `orjson` and `msgspec` using `package_is_available` from `utils.py`. + +## Testing + +This project uses `pytest` for testing. Adherence to good testing practices is crucial. + +* **Test Location:** Tests are located in the `tests/` directory. +* **Test Naming:** Test files `test_*.py`; test functions `test_*`. +* **Fixtures:** Utilize `pytest` fixtures (`@pytest.fixture`) for setup. + * **Project Pattern:** The `LoggingEnvironment` dataclass and `env` fixture in `tests/test_formatters.py` is a key pattern for testing logger behavior. Adapt this for similar scenarios. +* **Parametrization:** Use `@pytest.mark.parametrize` extensively to cover multiple scenarios efficiently. +* **Clarity and Focus:** Each test should be focused and its name descriptive. +* **Assertions:** Use clear, specific `pytest` assertions. + +By following these guidelines, we can ensure that `python-json-logger` remains a high-quality, maintainable, and developer-friendly library. From 0deb63fbe84d741abdb430d763fc02cbf82c7997 Mon Sep 17 00:00:00 2001 From: Nicholas Hairs Date: Thu, 26 Jun 2025 20:52:47 +1000 Subject: [PATCH 3/3] Update docs/quickstart.md --- docs/quickstart.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/quickstart.md b/docs/quickstart.md index 515bab6..3613aa4 100644 --- a/docs/quickstart.md +++ b/docs/quickstart.md @@ -105,7 +105,7 @@ formatter = JsonFormatter( ### Excluding fields -You can prevent fields being added to the output data by adding them to `reserved_attrs`. By default all [`LogRecord` attributes](https://docs.python.org/3/library/logging.html#logrecord-attributes) are exluded. +You can prevent fields being added to the output data by adding them to `reserved_attrs`. By default all [`LogRecord` attributes](https://docs.python.org/3/library/logging.html#logrecord-attributes) are excluded. ```python from pythonjsonlogger.core import RESERVED_ATTRS