Allow nested classes in NamedTuple bodies

[sobolevn]

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!

[sobolevn]

This does not look good, fixing.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[hauntsaninja]

Nice!

[sobolevn]

I want to hear from @ilevkivskyi as well, because of recent #14119

Thanks, @hauntsaninja, for the review :)

[sobolevn]

After reading feedback in #15064 I realize that this needs some more work.

[sobolevn]

This is going to be much harder than I expected :)

[sobolevn]

Solution suggested by @JukkaL gave this idea: we can split the semanal passes over named tuple class definition. I think the best option is:

1. Analyze nested classes
2. Analyze fields and methods
3. Re-analyze everything

[sobolevn]

Well, to do this I had to refactor almost all logic related to NamedTuple class definitions.
I don't really think that it is worth it right now :(

[sobolevn]

I think that this PR can be reviewed separately: it still allow defining a class inside a NamedTuple, but it does not allow using this class in annotations, which is very rare.

[sobolevn]

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

[ilevkivskyi]

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)

[hmc-cs-mdrissi]

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.

[ilevkivskyi]

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.