-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
pyclbr rewrite using AST #83592
Comments
pyclbr currently uses token streams to analyze but it can be alot simpler with usage of AST. There are already many flaws, including some comments about limitations of this token stream processing. I have a draft about this. Initial PR wont change any behavior, it will just make code much simpler with the usage of AST (just an addition to Function about handling of async functions, is_async field). If agreed I can propose a second PR (or append the inital one) that will enhance Function/Class objects with various identifiers (like keywords, metaclasses, end position information etc.). The second PR will be alot easier to do thanks to AST. |
Nice. A few notes. Docs: The initial doc paragraph now has 'module browser' rather than 'class browser'. The change is needed 2 other places. Could be part of this PR or another one.
Possible API changes based on IDLE module browser experience:
|
Thanks for the suggestions Terry, I didn't want to change any behavior or make any feature addition (except is_async as stated in issue description) in this PR.
I have a friend who would like to make his first contribution, so if it is not going to be problem, he'll take care of class browser references.
Yes, it would be way better use tree/node structre instead of returning raw dictionaries. I can draft something after PR 1803 is merged. I dont have much experience of IDLE's architecture, but I can try to help if you want on the 4th point. Another thing I was considering is deprecating |
A separate doc change issue and PR would be fine. Should we add a note explaining the module name as a contraction of an originally restricted scope? Make me nosy and invite review. Actually, a doc issue for the module as is should *fully* explain readmodule_ex first (its entry is now incomplete), and then explain readmodule as a filtered version kept for back compatibility. This could be a separate PR on the same issue, written by one of us, if too much for your friend. I understood limits of this PR. I should have said change notes were intended for your 'second PR'. Changing the return value to a Module should mean a third function, which would then become the main function, as readmodule_ex would then be Module.children. I have thought about making it possible to browse non-source modules, at least for the module being browsed. I might implement that first in IDLE. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: