fix(python): make class declarations and references agree on type names#4807
Merged
dbrattli merged 2 commits intoJul 17, 2026
Merged
Conversation
dbrattli
added a commit
that referenced
this pull request
Jul 17, 2026
Follow-up to #4807. Add a regression test for the overload-suffix casing path on a lowercase type name: an overloaded constructor is emitted as a module-level name (`shape__ctor_z<hash>`) and imported across files, so the declaration and the import must agree on the suffix casing, not just the base name. The existing `type shape` has a single constructor and so never exercised the suffix path. Also expand the comments in `getMemberDeclarationName` to describe what the unconditional `toPythonNaming` on the composed name actually does: it mirrors the re-casing applied at import/reference sites (keeping declarations and references consistent), but as a side effect overrides the [<CompiledName>] skip for root-level compiled names that start lowercase and thus have no uppercase entity/module prefix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4806
Class declarations are PascalCased on the Python target, but references to them are not, so a type with a lowercase name gets declared as class Shape while other modules import shape:
First commit: all entity names funnel through
getEntityDeclarationName, so the PascalCasing is applied there (Python branch only) and declarations and references agree by construction. The same commit fixes the equivalent mismatch for member names: reference sites re-case the full composed name, so a lowercase member with an overload suffix was declared asshape__ctor_Z524259A4but imported asshape__ctor_z524259a4. The composed declaration name now gets the same casing convention.Second commit: when an imported union's name collides with a local declaration, the import is correctly aliased (
Direction as Direction_1) butmakeEntityTypeAnnotationdiscarded the returned local identifier and emitted the original name, which fails with aNameErrorinsideStaticProperty[...]annotations. Annotations now use the actual (possibly aliased) import identifier.Only types whose names aren't already PascalCase produce different output than before, and references to those were broken one way or another.
Note that
toPascalCaseonly upper-cases the first character, which is why types nested in modules (mangled toModule_name) never hit this.