This was a problem before your PR, but I'm not sure what the justification is for not importing__about__ and__author__ in the generated stub here, given that they're included in__all__ at runtime

Yes, they're in IGNORED_DUNDERS in stubutil.py. It generally makes sense to exclude these names as they're not useful in stubs, but we shouldn't ignore them if they're in__all__.

Pushed a change so that IGNORED_DUNDERS aren't ignored if they're in__all__.

Hmm. Maybe it's problematic if stubgen adds__all__ to the generated stub, even though a symbol in__all__ at runtime (in this case,g) isn't actually defined at runtime. On the other hand, maybe it's outside of stubgen's purview to worry about such things; maybe it should just copy the runtime__all__ faithfully into the stub even when__all__ is weird at runtime, as you're doing now.

It's probably better to omit the undefined names so the generated stub won't create errors for type checkers, so I pushed that change. Could go either way though.

(For future readers of this thread: we decided to go back on this; see the discussion in#16356 (comment) for why)

I think I prefer stubtest's heuristic here, which IIRC is something like:

1. If the runtime has__all__:
   a. If a name is included in__all__, treat it as public
   b. Else, treat the name as private
2. If the runtime doesn't have__all__:
   a. If the name doesn't start with_, treat it as public
   b. Else, if the name is a dunder, treat it as public unless it's one of the ones in the "excluded dunders" list
   c. Else, treat it as private

The key difference is that (IIUC) the current algorithm you have here would treatbar as a public name in this situation, whereas stubtest would treat it as private:

__all__= ["foo"]foo=2bar=3

If we changed this algorithm in the way I'm suggesting, though, it would have an impact on existing tests such astestIncludeClassNotInAll_inspect. It would be a fairly big behavioural change. Probably best to leave it to another PR!

Possibly we should change this, but that feels out of scope for this PR; the logic is mostly as it was before, except that names in__all__ are now not treated as private. Your suggested change might be right, but it's better handled as an independent change.

kinda cool that stubgen has sophisticated enough inference to do this. Didn't realise that it had this capability!

Not sure about this. Stubtest would emit an error here if it encountered this, since__all__ is different in the stub to what it is at runtime. Rather than trying to synthesise a "corrected version of__all__", I think stubgen should just omit it from the generated stub in this situation

Omitting it also feels wrong though, and should generate a stubtest error (not sure if it currently does). Maybe the best option is to just emit__all__ as it is at runtime, even if it includes some undefined names.

Stubtest doesn't complain if__all__ is omitted at runtime, no (though I think itshould -- see#13300).

We're in a bit of a catch-22 here if the runtime__all__ has members that don't exist at runtime. In terms of typeshed's CI:

1. If__all__ is different in the stub to what it is at runtime, then stubtest will complain.
2. If__all__ in the stub contains members that don't exist in the stub, pyright will complain.
3. If__all__ is present at runtime but omitted in the stub, then neither will complain but, as you say, maybe stubtestshould complain...

I think you're right that emitting__all__ as it is at runtime is probably the least opinionated thing to do. Maybe we should just add a comment in the test cases to say that we know this is weird, but there's no obviously correct solution for this situation

Agree, and both stubtest and pyright are correct in those errors. Ultimately if__all__ contains a name that doesn't exist, that's a bug in the runtime library, and it seems right that to work around it in typeshed we'll have to ignore an error (either through the stubtest allowlist or a type ignore).