-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow nested classes in NamedTuple
bodies
#15776
base: master
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
This does not look good, fixing. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
1 similar comment
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
While working on #15776 I've noticed that some `RuntimeError` do not have enough metadata to understand what is going on. CI: https://github.com/python/mypy/actions/runs/5700479199/job/15450345887 This PR adds more context to error messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
I want to hear from @ilevkivskyi as well, because of recent #14119 Thanks, @hauntsaninja, for the review :) |
After reading feedback in #15064 I realize that this needs some more work. |
This is going to be much harder than I expected :) |
Solution suggested by @JukkaL gave this idea: we can split the semanal passes over named tuple class definition. I think the best option is:
|
Well, to do this I had to refactor almost all logic related to |
I think that this PR can be reviewed separately: it still allow defining a class inside a |
This is the example of how much changes are needed (just a single method): def analyze_namedtuple_classdef(
self, defn: ClassDef, tvar_defs: list[TypeVarLikeType]
) -> bool:
def analyze_class_internal(
defn: ClassDef, info: TypeInfo | None = None, *, first_pass: bool = False
) -> None:
if first_pass:
self.prepare_class_def(defn, info=info, custom_names=True)
self.setup_type_vars(defn, tvar_defs)
self.setup_alias_type_vars(defn)
with self.scope.class_scope(defn.info):
if first_pass:
for deco in defn.decorators:
self.analyze_class_decorator(defn, deco)
self.analyze_class_body_common(defn)
if defn.namedtuple_body_semanal is None:
info = self.named_tuple_analyzer.analyze_namedtuple_classdef_first_pass(
defn, self.is_func_scope()
)
analyze_class_internal(defn, info, first_pass=True)
# Second pass with actual fields:
self.enter_class(defn.info)
is_incomplete = self.named_tuple_analyzer.analyze_namedtuple_classdef(defn)
self.leave_class()
if is_incomplete:
self.defer(defn)
return
with self.named_tuple_analyzer.save_namedtuple_body(info):
analyze_class_internal(defn)
defn.namedtuple_body_semanal = None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW I can almost guarantee this will lead to crashes, but it is also hard to predict in which exact scenarios. My only suggestion would be to add a bunch of coarse grained and fine grained incremental tests, where these nested classes are added/modified (e.g. made generic)/deleted/renamed/replaced with a non-class with same name etc.
But also a more broad question: what is the value of supporting this? Are people asking for this often? (This is an honest question, e.g. a lot of people are asking for nested TypedDicts support)
My primary motivation for wanting this was code like this. Using older style namedtuple it is possible to define nested namedtuple and have code that becomes unclear how to write type stubs for. Maybe it would be fine from typing perspective to define class outside but to allow defining type alias to original nested class to allow any existing code that referenced nested class to continue to work. This is only place I have ever come across nested namedtuples. |
OK, I see, this use case looks similar to nested TypeDicts. The problem with type aliases is that supporting type aliases defined inside NamedTuples may be ~same amount of work @sobolevn mentioned to allow nested classes to be usable in annotations. |
Closes #15775
Closes #15752
Closes #15064
Refs #15680
I've taken test cases from #15064
Thanks a lot to @hmc-cs-mdrissi for working on it!