Intention-Revealing Naming

Write names that clearly communicate meaning, scope/intent, and project terminology—especially on public APIs/CLI and when calling helpers.

Apply:

• Match canonical terms: use the team/docs/external-provider wording for user-facing strings and public parameters (e.g., endpoint).
• Prefer explicit keywords in calls unless arguments are truly positional-only:
  • Prefer func(..., api_type=api_type, api_version=api_version) over relying on position.
• Use underscore markers to signal intent:
  • Use a single leading underscore (_name) for “internal/private by convention”.
  • Avoid double-underscore (__name) unless you specifically need name-mangling semantics.
  • Prefix intentionally-unused values/fixtures with _ to satisfy linters and show intent (e.g., _logger_with_filter).
• Avoid generic/ambiguous identifiers for integrations: choose distinct module/class names for integrations (e.g., wandb_logger / WandbLogger) rather than something indistinguishable from general logging.

Example:

api_type, api_version = cls._get_api_type_and_version(api_type, api_version)
url = cls._get_url("edits", None, api_type=api_type, api_version=api_version)

def _check_polling_response(...):
    ...  # internal by convention