← GDG /

#072 gdtest_long_docs

#072 gdtest_long_docs OK INIT
Very long docstrings with many sections
Three functions with very long docstrings containing multiple sections: Parameters, Returns, Raises, Notes, Examples (with code blocks), Warnings, References. On the Reference page each function should render all docstring sections fully โ€” nothing truncated.
View Site → Build Log ๐Ÿงช Test Coverage

Build Mode

○ No great-docs.yml

This package has no pre-supplied config. It tests the full great-docs initgreat-docs build pipeline from scratch, relying entirely on auto-detection of the package layout, docstring style, and exports.

Dimensions

A1 B1 C1 D1 E6 F6 G1 H7
A1Flat layoutlayout
B1Explicit __all__exports
C1Functions onlyobjects
D1NumPydocstrings
E6No directivesdirectives
F6No user guideuser_guide
G1README.mdlanding
H7No extrasextras

Source Files

๐Ÿ“ gdtest_long_docs/
๐Ÿ“„ __init__.py
"""Package with extensively documented functions."""

__version__ = "0.1.0"
__all__ = ["complex_transform", "detailed_validate", "full_process"]


def complex_transform(
    data: list,
    mode: str = "standard",
    threshold: float = 0.5,
    inplace: bool = False,
) -> list:
    """
    Apply a complex transformation to input data.

    This function performs a multi-step transformation on the input
    data. The transformation is controlled by the ``mode`` parameter,
    which can be ``"standard"``, ``"fast"``, or ``"precise"``.

    Parameters
    ----------
    data
        Input data as a list of numeric values. Each element must
        be a finite number (int or float). Empty lists are allowed
        and will return empty lists.
    mode
        Transformation mode. One of:

        - ``"standard"`` โ€” balanced speed/accuracy (default)
        - ``"fast"`` โ€” optimized for speed at cost of precision
        - ``"precise"`` โ€” maximum accuracy, slower
    threshold
        Minimum value threshold. Values below this are filtered
        out before transformation. Must be non-negative.
    inplace
        If True, modify the input list in place. If False (default),
        return a new list.

    Returns
    -------
    list
        Transformed data. If ``inplace=True``, this is the same
        object as ``data``.

    Raises
    ------
    ValueError
        If ``mode`` is not one of the recognized values.
    TypeError
        If ``data`` contains non-numeric elements.

    Notes
    -----
    The transformation algorithm is based on the windowed moving
    average technique described in [1]_. For large datasets
    (>10,000 elements), the ``"fast"`` mode is recommended.

    The time complexity is O(n) for ``"fast"`` mode and O(n log n)
    for ``"precise"`` mode.

    Warnings
    --------
    Using ``inplace=True`` modifies the original data and cannot
    be undone. Always make a copy if you need the original data.

    Examples
    --------
    Basic usage with default parameters:

    >>> from gdtest_long_docs import complex_transform
    >>> complex_transform([1, 2, 3, 4, 5])
    [1, 2, 3, 4, 5]

    Using fast mode:

    >>> complex_transform([1, 2, 3], mode="fast")
    [1, 2, 3]

    With threshold filtering:

    >>> complex_transform([0.1, 0.5, 1.0], threshold=0.3)
    [0.5, 1.0]

    References
    ----------
    .. [1] Smith, J. (2020). "Data Transformation Techniques."
       Journal of Applied Computing, 15(3), 42-58.
    """
    return data


def detailed_validate(
    schema: dict,
    data: dict,
    strict: bool = True,
) -> dict:
    """
    Validate data against a schema with detailed error reporting.

    Performs comprehensive validation of ``data`` against the
    provided ``schema`` dictionary. Each key in the schema maps
    to a type or validator specification.

    Parameters
    ----------
    schema
        Validation schema. Keys are field names, values are type
        objects or callable validators. Example::

            schema = {
                "name": str,
                "age": int,
                "email": lambda x: "@" in x,
            }
    data
        Data dictionary to validate.
    strict
        If True (default), raise on first error. If False,
        collect all errors and return them.

    Returns
    -------
    dict
        Validation report with keys:

        - ``"valid"`` (bool) โ€” overall result
        - ``"errors"`` (list) โ€” list of error messages
        - ``"fields_checked"`` (int) โ€” count of fields validated

    Raises
    ------
    ValueError
        If ``strict=True`` and validation fails.
    KeyError
        If schema references a field not present in data.

    Notes
    -----
    Schema validators receive the value and should return True
    for valid data or raise an exception/return False for invalid.

    Examples
    --------
    >>> detailed_validate({"name": str}, {"name": "Alice"})
    {'valid': True, 'errors': [], 'fields_checked': 1}
    """
    return {"valid": True, "errors": [], "fields_checked": len(schema)}


def full_process(
    items: list,
    pipeline: list = None,
    verbose: bool = False,
    max_workers: int = 1,
    timeout: float = 30.0,
) -> dict:
    """
    Process items through a configurable pipeline.

    Applies each stage in ``pipeline`` to the items sequentially
    (or in parallel if ``max_workers > 1``).

    Parameters
    ----------
    items
        List of items to process.
    pipeline
        List of callable stages. Each receives items and returns
        modified items. If None, uses a default pipeline.
    verbose
        If True, print progress information.
    max_workers
        Number of parallel workers. Use 1 for sequential.
    timeout
        Maximum processing time in seconds per stage.

    Returns
    -------
    dict
        Processing results with keys:

        - ``"items"`` โ€” processed items
        - ``"stages_run"`` โ€” number of stages executed
        - ``"elapsed"`` โ€” total time in seconds

    Raises
    ------
    TimeoutError
        If any stage exceeds the timeout.
    RuntimeError
        If a pipeline stage fails.

    Notes
    -----
    Parallel processing uses a thread pool. For CPU-bound stages,
    consider using ``max_workers=1`` to avoid GIL contention.

    Examples
    --------
    >>> full_process([1, 2, 3])
    {'items': [1, 2, 3], 'stages_run': 0, 'elapsed': 0.0}

    >>> full_process([1, 2, 3], pipeline=[str], verbose=True)
    Processing stage 1/1...
    {'items': ['1', '2', '3'], 'stages_run': 1, 'elapsed': 0.0}
    """
    return {"items": items, "stages_run": 0, "elapsed": 0.0}
๐Ÿ“„ README.md
# gdtest-long-docs

Tests functions with very long, multi-section docstrings.
๐Ÿ“„ great-docs.yml generated
# Great Docs Configuration
# See https://posit-dev.github.io/great-docs/user-guide/configuration.html

# Module Name (optional)
# ----------------------
# Set this if your importable module name differs from the project name.
# Example: project 'py-yaml12' with module name 'yaml12'
# module: yaml12

# Docstring Parser
# ----------------
# The docstring format used in your package (numpy, google, or sphinx)
parser: numpy

# Dynamic Introspection
# ---------------------
# Use runtime introspection for more accurate documentation (default: true)
# Set to false if your package has cyclic alias issues (e.g., PyO3/Rust bindings)
dynamic: true

# API Discovery Settings
# ----------------------
# Exclude items from auto-documentation
# exclude:
#   - InternalClass
#   - helper_function

# Logo & Favicon
# ---------------
# Point to a single logo file (replaces the text title in the navbar):
# logo: assets/logo.svg
#
# For light/dark variants:
# logo:
#   light: assets/logo-light.svg
#   dark: assets/logo-dark.svg
#
# To show the text title alongside the logo, add: show_title: true

# Funding / Copyright Holder
# --------------------------
# Credit the organization that funds or holds copyright for this package.
# Displays in sidebar and footer. Homepage and ROR provide links.
# funding:
#   name: "Posit Software, PBC"
#   roles:
#     - Copyright holder
#     - funder
#   homepage: https://posit.co
#   ror: https://ror.org/03wc8by49

# API Reference Structure
# -----------------------
# Customize the sections below to organize your API documentation.
# - Reorder items within a section to change their display order
# - Move items between sections or create new sections
# - Use 'members: false' to exclude methods from documentation
# - Add 'desc:' to sections for descriptions

reference:
  - title: Functions
    desc: Utility functions
    contents:
      - complex_transform
      - detailed_validate
      - full_process

# Site URL
# --------
# Canonical address of the deployed documentation site.
# Required for subdirectory deployments, skills page install commands,
# .well-known/ discovery, and sitemaps.
# site_url: "https://your-org.github.io/your-package/"

# Site Settings
# -------------
# site:
#   theme: flatly              # Quarto theme (default: flatly)
#   toc: true                  # Show table of contents (default: true)
#   toc-depth: 2               # TOC heading depth (default: 2)
#   toc-title: On this page    # TOC title (default: "On this page")

# Jupyter Kernel
# --------------
# Jupyter kernel to use for executing code cells in .qmd files.
# This is set at the project level so it applies to all pages, including
# auto-generated API reference pages. Can be overridden in individual .qmd
# file frontmatter if needed for special cases.
jupyter: python3

# CLI Documentation
# -----------------
# cli:
#   enabled: true              # Enable CLI documentation
#   module: my_package.cli     # Module containing Click commands
#   name: cli                  # Name of the Click command object