Lack of Clarity on Fix Responsibility

“`network-watcher packet-capture create`: unescaped `C:\Captures\...` in docstring emits SyntaxWarning on first run and corrupts the help example ### Describe the bug `src/azure-cli/azure/cli/command_modules/network/aaz/latest/network/network_watcher/packet_capture/_create.py`, line 21, has a Windows path inside the class docstring, which is a normal (non-raw) string: ``` "filePath": "C:\Captures\testByCli.cap" ``` That has two effects: 1. `\C` is an invalid escape sequence. Python has warned on invalid escapes by default since 3.12; on the 3.14.7 build tested here, the first import of the module (before its `.pyc` is cached) prints a `SyntaxWarning` to stderr. 2. `\t` is a valid escape, so it's consumed too: the example in `--help` ends up with blank space where `\t` was written, not the literal characters: `"C:\Captures estByCli.cap"`. The line is unchanged on `dev`. The file's last commit is #31624 (2025-06-18), well after aaz-dev-tools started escaping backslashes in generated docstrings (Azure/aaz-dev-tools#360, merged 2024-05-20). I don't know whether #31624 regenerated this file or just touched something else in it, so I can't say whether the fix belongs here, in the example source in Azure/aaz, or both. This isn't the `azure-batch` SDK warning tracked in #31789 / #32495. That one is in a different package; this file is owned by azure-cli. ### Related command `az network network-watcher packet-capture create` ### Errors First run after install (no `__pycache__` yet for that package): ``` $ az network network-watcher packet-capture create --help > /dev/null /opt/homebrew/Cellar/azure-cli/2.90.0/libexec/lib/python3.14/site-packages/azure/cli/command_modules/network/aaz/latest/network/network_watcher/packet_capture/_create.py:21: SyntaxWarning: "\C" is an invalid escape sequence. Such sequences will not work in the future. Did you mean "\\C"? A raw string is also an option. ``` The second run prints nothing, because the `.pyc` is cached by then. Help output (every run): ``` "/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/", "filePath": "C:\Captures estByCli.cap"}' --target "/subscriptions/*****/resourceGroups//providers/Micros ``` ### Issue script & Debug output This reproduces without relying on cache state, by compiling the file in memory with az's own interpreter: ```sh PY=/opt/homebrew/Cellar/azure-cli/2.90.0/libexec/bin/python # az's bundled Python F=$($PY -c "import azure.cli.command_modules.network as m, os; print(os.path.dirname(m.__file__))")/aaz/latest/network/network_watcher/packet_capture/_create.py $PY -c "import sys; p=sys.argv[1]; compile(open(p).read(), p, 'exec')" "$F" ``` Output: the same `SyntaxWarning` as above. And where the `\t` escape ends up: ```sh $PY -W ignore -c "from azure.cli.command_modules.network.aaz.latest.network.network_watcher.packet_capture._create import Create as C; d=C.__doc__; i=d.find('Captures'); print(repr(d[i-5:i+25]))" # ' "C:\\Captures estByCli.cap"}\' ' <- literal space, not "\t": confirmed chr(9) not in the string ``` ### Expected behavior No warning on stderr, and the help example shows `C:\Captures\testByCli.cap`. Escaping the backslashes (`C:\\Captures\\testByCli.cap`) fixes both. ### Environment Summary ``` azure-cli 2.90.0 (latest release), azure-cli-core 2.90.0 Python 3.14.7 (Homebrew bundle) macOS 26.6.2, arm64, installed via Homebrew ``` ### Additional context The warning only fires on the very first import, before the `.pyc` is cached (confirmed above). That's an easy trap for anything that merges stderr into parsed output (`2>&1`): it fails once, then passes silently on retry. A `SyntaxWarning` shouldn't be on stderr to begin with.”