💊 CI failures summary and remediations

As of commit ff8869c (more details on the Dr. CI page):

💚 💚 Looks good so far! There are no failures yet. 💚 💚

Looks good to me, thank you!

At the risk of pointing out the obvious: An alternative to changing the how to make global could be to re-implement the old inspect way of finding the source code. This could be advantageous for users that run into this, but I wouldn't know if it is common. Finding class source code is superhacky in Python...

@malfet merged this pull request in a949d7b.

An alternative to changing the how to make global could be to re-implement the old inspect way of finding the source code.

100% agree with you here, sounds like a good enhancement on the torch.jit frontend side.
@suo do you know if JIT needs source code for anything, but generating verbose error messages? (since JIT graph is generated from an AST, isn't it?)

The ast module requires source iirc. So I don't think there's a way to avoid retrieving source.

@t-vi: can you point me to the "old way" of doing inspect?

The ast module requires source iirc. So I don't think there's a way to avoid retrieving source.

Yes - we call ast.parse(source) to get the Python AST.

The change that breaks our tests appears to be python/cpython#10307

Now, I will grant them that the old way of "just match a regexp" is far from ideal, either. I didn't try but now that I look more closely, maybe the correct solution would be to augment the _ClassFinder of the recent versions with scope awareness including global statments.
Given Python's release cycles, we might want some workaround for 3.9 and 3.10 at least, but in principle going through the AST seems much more robust than the old indent+regexp. Maybe we should just do our own AST visiting to get the right source lines.

When I tried to propose Python adding source file information to classes (for the benefit of Jupyter), some people on the mailing list suggested exposing the code object defining classes or so, which would give filename + line numbers. Having the file + line numbers would, of course, make this robust and trivial. The technical aspects of getting Python to have proper source annotations for their classes aren't hard, but the process of getting that type of thing into Python heavy-handed enough to make me give up: you'd need a PEP with performance considerations, breakage opportunities (someone's code will assume that anything with a code object is a function etc.).