Skip to content

Tracking issue for specification maintenance tasks #533

@kgryte

Description

@kgryte
Contributor

The purpose of this issue is to identify and track various maintenance tasks which have accumulated concerning specification organization and development.

Remaining tasks

  • Migrate special cases to use math directives:
    Ensure line length is handled better, so text is readable and reviewable on GitHub without it scrolling off to the right. Either use regular line length settings (80, 88, 100, or 120 char), or set up something like EditorConfig to ensure consistent line endings and spacing.
    Setup linting of Python files (, ) in CI.

Done for v2022

  • Move special cases and other explanatory content to a dedicated "notes" section:
    • PR:
  • Add a short sentence about whether the special cases are derived from C99, from some other standard, or are based on analysis or existing practice in array libraries. See .
    • PR:
  • Use black for automated code formatting and line wrapping (possibly using Git hooks).
    • PR:
  • Move universal preamble content (e.g., positional parameters, optional parameters, etc) to a dedicated design document.
    • PR:
  • Merge the content in the "branch cuts", "complex number ordering" and "complex numbers" (about equality mostly) design topic pages into a single "complex number support" page.
    • PR:

Activity

rgommers

rgommers commented on Dec 1, 2022

@rgommers
Member

Thanks for summarizing this @kgryte. A few thoughts:

added this to the v2022 milestone on Dec 14, 2022
removed this from the v2022 milestone on Dec 21, 2022
rgommers

rgommers commented on Dec 21, 2022

@rgommers
Member

The v2022 tasks are done. I reorganized the description so it's clear what is left, and removed the milestone.

added this to the v2023 milestone on Dec 21, 2022
kgryte

kgryte commented on Jan 25, 2024

@kgryte
ContributorAuthor

As commented in #689 (comment), we should investigate whether we can minimize type annotation duplication. Currently, we copy-paste the type annotation from the signature into the docstring. This increases the risk of drift, and preferably, we'd only need to write these annotations once.

rgommers

rgommers commented on Jan 25, 2024

@rgommers
Member

Sphinx has functionality for that (autodoc_typehints), but like anything autodoc related it had some issues, especially with dealing with type aliases. Not sure if that has been improved recently, but I did try this when initially setting up the docs.

rgommers

rgommers commented on Jan 25, 2024

@rgommers
Member

If I had to deal with this now, I'd dump Sphinx complete in favor of MkDocs / mkdocs-material.

kgryte

kgryte commented on Jan 25, 2024

@kgryte
ContributorAuthor

Sphinx has functionality for that...I'd dump Sphinx completely...

Yeah, we should revisit once we have v2023 released.

modified the milestones: v2023, v2024 on Feb 8, 2024
modified the milestones: v2024, v2025 on Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    MaintenanceBug fix, typo fix, or general maintenance.Tracking IssueTracking issue.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @rgommers@kgryte

        Issue actions

          Tracking issue for specification maintenance tasks · Issue #533 · data-apis/array-api