-
Notifications
You must be signed in to change notification settings - Fork 59
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
IPython inspect.getsource()
failure due to incorrect co_firstlineno
#160
Comments
I guess some context might help motivate this one. I was converting Sasha Rush's tensor puzzles from torchtyping to jaxtyping, and the final cell of his exercise is a competition to make the "shortest one liner" to accomplish some standard torch function. After I finished the port, I noticed this "score board" wasn't working properly, and tracked it down to the above interaction. |
Hmm, that's a little odd! Digging into this a little, it seems like this is due to inspect.unwrap(ones).__code__.co_firstlineno (which is used inside Moreover I've checked and this doesn't seem to happen in normal usage; this is specific to the IPython extension. Tagging @knyazer -- what do you think might be going on -- something inside IPython itself maybe? Our AST transformations don't really do much beyond appending to the decorator list, after all. |
That's a very nice problem. After a bit of time, I came to the same conclusion, that the root cause is that First of all, there is a quick fix that I can propose for @davideger: instead of having one big cell, have three separate cells, like here (colab link). Another solution is to hand-annotate the functions instead of using the magic. But this does not solve the issue, it just avoids it. So let's dig further... I tracked down the issue to the level of the IPython magic: everything breaks if we attempt to add any decorator to the ast transformations list. The most interesting part is that adding even the pointer-copying decorator fails, even if wrapped with In the end, I only have a hypothesis about what is wrong (that is, the IPython wraps the magics incorrectly, but I am likely to be wrong), and I would prefer to monkey-patch it on the level of IPython anyways, not jaxtyping. So I think we should transfer this issue to the IPython issue tracker. |
Thanks for tracking down that this is not |
inspect.getsource()
inspect.getsource()
failure due to incorrect co_firstlineno
This colab shows an unexpected side effect of enabling automatic jaxtype checking in IPython: It causes
inspect.getsource
's to retrieve incorrect source text for a given function.That is, if I run these two cells:
Then I get:
'def ones(i: int) -> jaxtyping.Int32[torch.Tensor, "{i}"]:\n return arange(i) - arange(i) + 1\n'
But if I turn on type checking by using:
Then running the same
inspect.getsource(ones)
yields:'def where(q, a, b):\n "Use this function to replace an if-statement."\n return (q * a) + (~q) * b\n'
The text was updated successfully, but these errors were encountered: