-
Notifications
You must be signed in to change notification settings - Fork 22
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
Support standard library (Attempt 3) #109
Support standard library (Attempt 3) #109
Conversation
…x with both gast and ast without additional parameters.
…ing gast This should make it possible to derive from beniget to implement support for ast module in addition to gast module.
Idk why the tests failed, it works on my local computer and it looks like I can’t access the log of the GitHub CI. Can you help me @serge-sans-paille ? Thanks |
I really like where it's going! Some comments inline though |
return self.node.name | ||
elif _PY310PLUS and isinstance(self.node, ast.MatchMapping) \ | ||
and self.node.rest: | ||
return self.node.rest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the place I like the less, because we clearly loose the generic aspect of gast
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use __class__.__name__ == str
for these case to keep it generic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @serge-sans-paille, I’ve applied the suggested changes :)
@@ -559,17 +601,76 @@ def process_annotations(self): | |||
cb(visitor(annnode)) if cb else visitor(annnode) | |||
self._scopes = currenthead | |||
self.defs = compute_defs | |||
|
|||
def _support_stdlib(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: should / could that be put in a subclass?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This way simplifies the usage as well as the testing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But to answer your question: yes it could be a subclass. But there is no value for it to be put in a subclass instead of this.
Grand merci pour ton feed-back @serge-sans-paille ! |
…eveloment computers (tox).
I'm good with this! can you rebase & squash into a nice stack and we're done :-) |
Could you just use the « squash and merge » option of GitHub ? Thanks |
On Sat, Oct 12, 2024 at 02:37:58PM -0700, tristanlatr wrote:
Could you just use the « squash and merge » option of GitHub ? Thanks
No :-) There are conflicts.
If you can't handle it, I'll copy your branch and do it myself...
|
Manually rebased, squashed and merged as of de126b0 |
Fantastique, merci |
This attempt uses the
pkg()
function proposed in #101.This changes should probably be squashed since a lot of the commit messages are irrelevant.
For the record:
if node.__class__.__name__ == <str>
.ast
module only at strategics place and then storing it in aself.ast
variable.But in any case some methods needs to be added to the
DefUseChains
class and a couple of places needs to be adjusted to cope with structural differences in between ast and gast, for instance the fact that expect handlers name are stored asName
instead ofstr
andarg
doesn't exist ingast
.