Skip to content

Better indicate which utilities are private vs. public #10119

@jrbourbeau

Description

@jrbourbeau

We have lots of utilities throughout our codebase and we're not very vigilant about indicating which ones are intended to be public and which are private. Some methods like dask.utils._deprecated are marked as private

dask/dask/utils.py

Lines 78 to 85 in 0cbc46a

def _deprecated(
*,
version: str | None = None,
after_version: str | None = None,
message: str | None = None,
use_instead: str | None = None,
category: type[Warning] = FutureWarning,
):

but most aren't marked with a leading underscore and also aren't meant for public consumption.

This lack of public vs. private specification causes issues like #10112. I think we should move utilities are that are intended to be private into a private module (e.g. dask._utils) -- we'll also want to emit deprecation warnings appropriately.

Note that we do have some public utilities, so this wouldn't be a blanket "move everything into private modules". But I suspect most things in, for example, dask.utils_test and dask.compatibility can be moved over into private modules (xref #10114).

cc @jacobtomlinson for visibility

Also cc @fjetter @crusaderky @hendrikmakait as I think the same argument applies to dask/distributed

Metadata

Metadata

Assignees

No one assigned

    Labels

    hygieneImprove code quality and reduce maintenance overheadneeds attentionIt's been a while since this was pushed on. Needs attention from the owner or a maintainer.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions