Skip to content

Move tname__ to base_shapes to reduce noise in interface classes.#926

Merged
dnwpark merged 3 commits intomasterfrom
shapes-tname
Sep 26, 2025
Merged

Move tname__ to base_shapes to reduce noise in interface classes.#926
dnwpark merged 3 commits intomasterfrom
shapes-tname

Conversation

@dnwpark
Copy link
Contributor

@dnwpark dnwpark commented Sep 24, 2025

followup to #918

tname__ was added to the user facing types. For example, in models.orm.default:

class User(base_shapes.User, Named):
    """type default::User"""

    tname__: Literal["default::User"] = Field("default::User", alias="__tname__")
    groups: ComputedMultiLink[UserGroup]

This PR would moves tname__ to base_shapes.User.

@dnwpark dnwpark changed the base branch from master to replace-reveal-type September 24, 2025 17:13
@dnwpark dnwpark force-pushed the shapes-tname branch 2 times, most recently from 4a55950 to 4a150dc Compare September 24, 2025 19:21
@dnwpark dnwpark changed the base branch from replace-reveal-type to master September 24, 2025 19:21
@dnwpark dnwpark closed this Sep 24, 2025
@dnwpark dnwpark reopened this Sep 24, 2025
@dnwpark dnwpark marked this pull request as ready for review September 25, 2025 04:10
# which are the ones that directly declare 'tname__'
(tname := getattr(reflection, "name", None)) is not None
and 'tname__' in namespace
and any('tname__' in base.__dict__ for base in bases)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sigh I guess this is fine.

Also update the comment above this, which is now wrong.

Add that tname__ isn't in namespace itself, then, I think?
Since the base shape also has base shape children, and we don't want those to get picked up.
(I don't know if it would be a bug for them to get picked up here, since they'd be correctly overwritten by their defined-later real children, but still.)

@dnwpark dnwpark merged commit 569d3a5 into master Sep 26, 2025
43 checks passed
@dnwpark dnwpark deleted the shapes-tname branch September 26, 2025 01:57
msullivan added a commit that referenced this pull request Sep 29, 2025
…ular

I ran into a few things here:
 - The object.pyx code to handle decoding to subclasses only looks
   at __subclasses__, and so misses grandchildren types. I clearly
   remember thinking about this and testing the grandchild case,
   but apparently I missed something there.
 - Descendants of std::Object in particular get immediately screwy,
   because user-facing types don't inherit from std::Object directly,
   but instead their __shapes__ do.
 - The new "`tname__` in `__shapes__`" mechanism (#926) was putting
   wrong stuff in the map in some cases.

My approach is to explicitly indicate which classes should be
considered the canonical decoding classes with a `__gel_is_canonical__
= True` field on the class. And for now, I'm populating it explicitly,
though we can probably write a bunch of nasty logic to figure it out too.
msullivan added a commit that referenced this pull request Sep 30, 2025
…ular (#938)

I ran into a few things here:
 - The object.pyx code to handle decoding to subclasses only looks
   at `__subclasses__`, and so misses grandchildren types. I clearly
   remember thinking about this and testing the grandchild case,
   but apparently I missed something there.
 - Descendants of std::Object in particular get immediately screwy,
   because user-facing types don't inherit from std::Object directly,
   but instead their `__shapes__` do.
 - The new "`tname__` in `__shapes__`" mechanism (#926) was putting
   wrong stuff in the map in some cases.

My approach is to explicitly indicate which classes should be
considered the canonical decoding classes with a `__gel_is_canonical__
= True` field on the class. And for now, I'm populating it explicitly,
though we can probably write a bunch of nasty logic to figure it out
too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants