fix(http-client-python): don't corrupt TypedDict literal values matching builtin names

[Libba Lawrence (l0lawrence)]

Problem

In the Python HTTP client emitter, a TypedDict literal value that coincides with a Python builtin type name got corrupted into builtins.X in the generated types.py:

class TypeParam(TypedDict, total=False):
    type: Required[Literal["builtins.type"]]   # WRONG — should be Literal["type"]
    text: Required[str]

The TypeSpec source (type: "type";) is correct; the corruption is introduced purely by the emitter.

Root cause

packages/http-client-python/generator/pygen/codegen/serializers/types_serializer.py has a TypedDict-only builtin-shadowing workaround: when a field's wire name is a Python builtin type name (e.g. bytes, int, type) and a sibling field is annotated with that bare builtin, pyright errors reportInvalidTypeForm (the earlier field shadows the type). To avoid that, the serializer qualifies the builtin as builtins.X.

Both the detection (get_shadowed_builtins) and the application (_qualify_shadowed_builtins) used a naive \bname\b regex that also matched inside string literals like Literal["type"], so:

• literal values (and quoted forward references) were rewritten into builtins.X, and
• spurious import builtins statements were emitted.

A second, related issue: detection ran against the default annotation while emission uses the TYPES_FILE annotation. Under TYPES_FILE some types change (bytes/datetime → str, decimal → float), so detection could both miss real shadowing and flag false ones.

Fix

• _qualify_shadowed_builtins and the detection helper are now string-literal-aware: the annotation is split on single/double-quoted spans and the \bname\b substitution only runs on code segments. A (?<!\.) lookbehind also skips already-dotted names (no builtins.builtins).
• get_shadowed_builtins now detects shadowing against the actually-emitted (TYPES_FILE) annotation, so genuine sibling-builtin shadowing is still qualified while literal values / quoted forward references are left untouched, and no spurious import builtins is emitted.

Surgical change; no unrelated refactoring.

Behavior preserved

The legitimate case is still qualified (verified with pyright):

class Blob(TypedDict, total=False):
    int: Required[str]
    count: Required[builtins.int]   # genuine sibling-builtin shadowing -> still qualified

Tests

• Added unit coverage in tests/unit/test_typeddict.py (36 pass), covering: (a) a Literal value coinciding with a builtin name is not rewritten; (b) a quoted forward reference is left untouched; (c) genuine sibling-builtin shadowing is qualified to builtins.X; (d) already-dotted names are not double-qualified; (e) no spurious import builtins for the false-positive; and (f) types that change under TYPES_FILE don't cause spurious imports.

Regeneration

Regenerated the full test corpus (azure + unbranded) with and without the change. Zero diff — the fix is behavior-preserving:

• The existing genuine case (typetest-union, a field named int with builtins.int siblings) is retained unchanged.
• No existing spec has a literal value that coincides with a builtin name, so the false-positive path isn't exercised by the corpus; it is covered directly by the new unit tests.

Validation

• pytest tests/unit/test_typeddict.py → 36 passed
• pylint 10.00/10; black clean on changed lines

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-python@11268

commit: 4cc4ea8

[github-actions]

All changed packages have been documented.

• ✅ @typespec/http-client-python

Show changes

@typespec/http-client-python - fix ✏️

Fix a bug where a TypedDict literal value that coincides with a Python builtin type name (e.g. type: "type") was corrupted into Literal["builtins.type"] in the generated types.py. The builtin-shadowing workaround now ignores identifiers inside string literals (literal values and quoted forward references are left untouched) and detects shadowing against the actually-emitted annotation, so genuine sibling-builtin shadowing is still qualified while spurious import builtins statements are no longer emitted.

[azure-sdk-automation]

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension