Python 3.13/3.14 SyntaxWarning in v1 LogsPipelinesApi docstring

Start with src/datadog_api_client/v1/api/logs_pipelines_api.py and inspect the LogsPipelinesApi class docstring around the reported regex text. Run the supplied Python command with warnings enabled to reproduce the warning, then verify that importing the module no longer emits it. Done means the offending sequence is represented safely and the import remains successful.

Describe the bug
Importing datadog_api_client.v1.api.logs_pipelines_api emits a SyntaxWarning on Python 3.13+ because the LogsPipelinesApi class docstring contains an unescaped regex sequence: \s.

The warning appears to come from this docstring text in src/datadog_api_client/v1/api/logs_pipelines_api.py:

that uses a regex pattern like ``\s`` for spaces, you will

Because Python docstrings are normal string literals, \s is parsed as an invalid escape sequence. Escaping it as \\s or generating the docstring as a raw string should avoid the warning.

To Reproduce
Run this with warnings enabled on Python 3.13 or 3.14:

python -W default -c "from datadog_api_client.v1.api.logs_pipelines_api import LogsPipelinesApi; print(ok)"

Observed output:

.../datadog_api_client/v1/api/logs_pipelines_api.py:38: SyntaxWarning: "\s" is an invalid escape sequence. Such sequences will not work in the future. Did you mean "\\s"? A raw string is also an option.
  """
ok

Expected behavior
Importing the SDK module should not emit warnings.

Screenshots
Not applicable.

Environment and Versions (please complete the following information):

• datadog-api-client: observed locally with 2.54.0
• Python: reproduced locally with Python 3.14.0rc2; expected to affect Python 3.13+ warning behavior
• Module: datadog_api_client.v1.api.logs_pipelines_api
• Repository master checked on 2026-05-17 still contains the same unescaped docstring sequence
• Latest PyPI version observed on 2026-05-17: 2.55.0

Additional context
This surfaced when importing CLI code that depended on the Logs Pipelines API. The workaround on our side was to lazy-load this SDK module so unrelated CLI invocations do not emit SDK import warnings, but the underlying issue appears to be in the generated SDK docstring.