-
Notifications
You must be signed in to change notification settings - Fork 370
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
Unable to view some docstrings with => (help modulename) #2578
Comments
Perplexing. It looks like Python wants to try to reparse the source file (as Python) even though all the docstrings it wants should already exist at runtime. I'm not sure Hy can fix this, but I'll look into it. |
It seems to occur whenever a Hy source file contains a |
There it is:
|
Thank you for looking at that. Unfortunately, it breaks a use case where I use Since you are monkey-patching inspect anyway, could I suggest that monkey-patching If you're agreeable to that approach, I'll work on a patch. I'm aware you would want a test. |
I'm not so sure. Hy's syntax is Turing-undecidable (because of reader macros); it has complex nested structures (such as bracket f-strings) that are difficult to match properly with regexes; and macros can produce code with bogus position information. But the proof is in the pudding. |
I think I have sorted this out by patching inspect. This would also solve #1696. See https://github.com/atisharma/hy/blob/inspect-compat/hy/_compat.py which fixes:
If this approach is acceptable then I'll finish writing tests and proceed. If you want changes (e.g. it's quite long - would you prefer hy._inspect.py?) or if I'm barking up the wrong tree, then of course let me know. |
I think calling I haven't tested your |
I see your point, but doesn't calling help on an object mean the object has already been through the reader once, since it's in the namespace? There is no way to locate a class without either following the syntax tree (which is what python's inspect._ClassFinder does) or guessing with regexes, which has its own problems, as you pointed out. I don't see any other way.
This is expected behaviour. Python's inspect.getcomment only shows comments with a hash Since all the functions rely on I do appreciate that patching inspect is not to be taken lightly. |
Sure, but one of the things about arbitrary code is that running it can have a different effect the second time. Besides, there's no guarantee that the file hasn't changed, so you might execute different code, after all.
You could change the compiler to cache what you need when the code is originally compiled, perhaps. But simply not implementing this is probably reasonable.
When I say "fooled with", I mean that those things could be mistaken for comments by your text-processing code, not that the code ought to treat them as comments and fails to. I could construct an example if this isn't clear. |
Well, the user has already made the decision to trust the code by that point, but I can see why you're not keen. I can implement caching the python ast for use in In the meantime, your patch is lighter touch and fixes the |
I also have another PR you might like better, which patches |
I came across a strange error causing problems viewing the docstring of a module. Below is my setup and a minimum working example.
results in the following error:
Commenting out the class definition removes the error. Removing the docstring preserves the error.
The text was updated successfully, but these errors were encountered: