Drift
sdks/python/pmxt/models.py defines five reusable, non-underscore-prefixed names — OutcomeType (line 20), MinMax (line 695), DateRange (line 700), PriceFilter (line 705), and VenueFilter (line 863) — none of which are imported into sdks/python/pmxt/__init__.py or listed in its __all__. from pmxt import OutcomeType (or any of the other four) raises ImportError today; they're reachable only via from pmxt.models import OutcomeType.
This directly contradicts the stated premise of two already-open issues:
Neither claim is accurate against the current source: these five names are not part of the Python package's public root surface at all.
TypeScript's package barrel (sdks/typescript/index.ts:49) does export type * from "./pmxt/models.js", a wildcard re-export that automatically surfaces every type declared in models.ts — present and future — with no manual allow-list step. Once #2075's companion fix PR (#2083, "fix(typescript): export OutcomeType alias") lands and TypeScript gains a named OutcomeType, it will be reachable as import { OutcomeType } from "pmxt" immediately and automatically. Python's __init__.py uses a manually curated __all__/import list instead, and that list has simply missed these five names.
TypeScript SDK
sdks/typescript/index.ts:49 — export type * from "./pmxt/models.js" re-exports every type in models.ts without curation. (After #2083 lands, this will include the new OutcomeType.)
Python SDK
sdks/python/pmxt/models.py:20,695,700,705,863 define OutcomeType, MinMax, DateRange, PriceFilter, VenueFilter. None of the five appear anywhere in sdks/python/pmxt/__init__.py (verified: no match for any of these five names in that file) — not in the from .models import (...) block and not in __all__. from pmxt import OutcomeType currently raises:
ImportError: cannot import name 'OutcomeType' from 'pmxt'
Expected
Add all five names to sdks/python/pmxt/__init__.py's import block and __all__ so from pmxt import OutcomeType (etc.) works, matching TypeScript's automatic full re-export. This should be fixed alongside (not instead of) #1441/#2075's TypeScript-side naming fix — landing #2083 alone, without this, leaves the asymmetry in place just with the languages swapped: TS would gain the export Python is assumed to already have, while Python's own OutcomeType remains unreachable at the package root.
Impact
Users following #2075's own example (from pmxt import OutcomeType) to write cross-SDK-compatible type annotations hit an ImportError in Python today. Any fix informed only by #1441/#2075's current wording risks "fixing" TypeScript to match a Python behavior that doesn't actually exist.
Found by automated SDK cross-language drift audit
Drift
sdks/python/pmxt/models.pydefines five reusable, non-underscore-prefixed names —OutcomeType(line 20),MinMax(line 695),DateRange(line 700),PriceFilter(line 705), andVenueFilter(line 863) — none of which are imported intosdks/python/pmxt/__init__.pyor listed in its__all__.from pmxt import OutcomeType(or any of the other four) raisesImportErrortoday; they're reachable only viafrom pmxt.models import OutcomeType.This directly contradicts the stated premise of two already-open issues:
MinMax,DateRange,PriceFilter,VenueFilter,OutcomeType) that TypeScript only inlines anonymously #1441 ("SDK drift: Python exports named reusable filter-shape types (MinMax,DateRange,PriceFilter,VenueFilter,OutcomeType) that TypeScript only inlines anonymously")OutcomeTypeliteral alias; TypeScript inlines the same union with no equivalent name #2075 ("Python exports a namedOutcomeTypeliteral alias..." — body explicitly states "Python consumers canfrom pmxt import OutcomeType")Neither claim is accurate against the current source: these five names are not part of the Python package's public root surface at all.
TypeScript's package barrel (
sdks/typescript/index.ts:49) doesexport type * from "./pmxt/models.js", a wildcard re-export that automatically surfaces every type declared inmodels.ts— present and future — with no manual allow-list step. Once #2075's companion fix PR (#2083, "fix(typescript): export OutcomeType alias") lands and TypeScript gains a namedOutcomeType, it will be reachable asimport { OutcomeType } from "pmxt"immediately and automatically. Python's__init__.pyuses a manually curated__all__/import list instead, and that list has simply missed these five names.TypeScript SDK
sdks/typescript/index.ts:49—export type * from "./pmxt/models.js"re-exports every type inmodels.tswithout curation. (After #2083 lands, this will include the newOutcomeType.)Python SDK
sdks/python/pmxt/models.py:20,695,700,705,863defineOutcomeType,MinMax,DateRange,PriceFilter,VenueFilter. None of the five appear anywhere insdks/python/pmxt/__init__.py(verified: no match for any of these five names in that file) — not in thefrom .models import (...)block and not in__all__.from pmxt import OutcomeTypecurrently raises:Expected
Add all five names to
sdks/python/pmxt/__init__.py's import block and__all__sofrom pmxt import OutcomeType(etc.) works, matching TypeScript's automatic full re-export. This should be fixed alongside (not instead of) #1441/#2075's TypeScript-side naming fix — landing #2083 alone, without this, leaves the asymmetry in place just with the languages swapped: TS would gain the export Python is assumed to already have, while Python's ownOutcomeTyperemains unreachable at the package root.Impact
Users following #2075's own example (
from pmxt import OutcomeType) to write cross-SDK-compatible type annotations hit anImportErrorin Python today. Any fix informed only by #1441/#2075's current wording risks "fixing" TypeScript to match a Python behavior that doesn't actually exist.Found by automated SDK cross-language drift audit