Skip to content

Conversation

sterliakov
Copy link
Collaborator

@sterliakov sterliakov commented Aug 29, 2025

Currently stubtest allows unsound definitions:

# a.pyi
from enum import Enum
class E(Enum):
    _value_: str
    FOO = ...
# a.py
from enum import Enum
class E(Enum):
    FOO = 0

This PR teaches stubtest that _value_ attribute (spec) should be used as a fallback in such case.

elif runtime_type is not None and is_subtype_helper(runtime_type, value_t.type):
should_error = False
elif runtime_type is not None:
note = " (incompatible '_value_')"
Copy link
Collaborator

@A5rocks A5rocks Aug 30, 2025

Choose a reason for hiding this comment

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

Is this intentionally making the runtime_type is None case error now? (I tried thinking about it but IDK what that means. I also don't know stubtest very well :^)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I also tried thinking about that, couldn't invent a case where we have found an attribute but failed to interpret its value, and decided to be cautious, reporting such "smth weird" cases as incompatibilities. Maybe this should be an assert, but I'm afraid to accidentally kill stubtest right before release...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Okay, almost all other checks do not reject "wtf" values as incompatible, updated for consistency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants