Skip to content
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

Recognize subjects other than Name nodes #4

Closed
Tirasz opened this issue Oct 28, 2021 · 2 comments
Closed

Recognize subjects other than Name nodes #4

Tirasz opened this issue Oct 28, 2021 · 2 comments
Assignees

Comments

@Tirasz
Copy link
Owner

Tirasz commented Oct 28, 2021

Right now the subject must be a string (id), that is used to construct a Name node.
This limits tranforming capabilities, for example:

if obj.attr = 2 or obj.attr = 3:
    do_something()
elif (obj.attr = 12 or obj.attr = 24) and something():
    do_something()

Could be transformed with LiteralCase to:

match obj.attr:
    case 2 | 3:
        do_something()
    case 12 | 24 if something():
        do_something()

If the plugin was able to recognize that obj.attr could be a subject, even though its not just a single Name() node.
I think this could be changed, by modifying the get_subject, _get_subject, and get_const_node methods.

@Tirasz Tirasz self-assigned this Oct 28, 2021
@Tirasz
Copy link
Owner Author

Tirasz commented Oct 28, 2021

First, i tried to just modify the _get_subject() method, to return a node.
(instead of just recognizing a Name node, and returning its id)
Then, i modified the get_const_node method, since this also depended on the subject being a Name node.

Then came the hard part:
Since I used the id-s of Name nodes before, (strings), it was easy for me to put them into sets and manipulate them.
But now, I'm using actual Node-s (objects). This sadly meant, that two, completely identical subjects were treated as if they were different, since technically, they were different objects.
The reason for that is, is that python is using the default, eq() method for comparing two objects, which just compares their addresses in memory.
Maybe I have a way of overwriting this method for all the different types of nodes, but i dont know how good of an idea that is.

I decided that the easiest way to check if two subjects are equal, is to compare their ast.dump()-s.
(First of all, im not sure if this is actually correct for every possibility, and Im also not sure if this is the most efficient way of doing this)
But since there is no method for going from a dump to an actual node object, i couldnt just use this "representation" of the nodes alone.
To solve this, i made a dictionary (ofc) that maps dumps to actual node objects.
I made sure, that if a dump is already a part of its keys, i dont overwrite its value, since my point with this, is that i want identical subjects to have an identical node object representing them.

With this, i just had to make sure that the analyzers were returning this "representative" object, so that in the main analyzer i could manipulete them using sets, just like with the Name node id-s.

@Tirasz
Copy link
Owner Author

Tirasz commented Nov 12, 2021

By "monkey-patching" the ast.AST.__hash__ method, to return a hash of the node's ast.dump(), and the ast.AST.__eq__ method, to compare the hashes of two nodes, I managed to make the process a bit simpler.
Doing this allows me to just put the subjects into sets, without having the problem of two identical subjects being treated as two different objects.
Now I just have to wait for the day when this 'patch' is going to bite me in the ass.
Until then, it works fine.

@Tirasz Tirasz closed this as completed Nov 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant