Skip to content

Poor if statement formatting with Python 2.4 decompilation #178

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

Closed
pythonengineer opened this issue May 25, 2018 · 7 comments
Closed

Poor if statement formatting with Python 2.4 decompilation #178

pythonengineer opened this issue May 25, 2018 · 7 comments

Comments

@pythonengineer
Copy link

When decompiling a Python 2.4 module, something such as this:

if True:
    pass
elif False:
    pass
elif not True:
    pass

will be decompiled as:

if True:
    pass
else:
    if False:
        pass
    else:
        if not True:
            pass
@rocky
Copy link
Owner

rocky commented May 25, 2018

All decompilers have to be satisfied with semantic equivalence. That code is semantically equivalent, so this is not a bug.

That said, I suppose most people would prefer the more compact form. The right way to address this in the future would be to make a pass over the syntax tree to look for such constructs to collapse them. See #141

Is that something you are interested in undertaking?

@pythonengineer
Copy link
Author

@rocky I definitely understand, but this can actually be very annoying if there are several else ifs and it ends up looking something like this:

                                                                                                                                      if True:
                                                                                                                                          pass

Unfortunately, I don't really understand how the uncompyle internals work, and while I could learn them, I already have a lot of work to do with other projects, but I wish I could attempt to debug it. I made this issue more so that you and other devs know that it exists to be looked into in the future.

@rocky
Copy link
Owner

rocky commented May 25, 2018

Sure, I can understand how busy you must be. Thanks for taking the time to jot this down. There's no rush on this, so this can wait until someone finds the urge to address it.

@pythonengineer
Copy link
Author

@rocky Something I forgot to ask, I was using whatever the latest commit was in the master branch at the time to get that result. I didn't notice that there was a "Python 2.4" branch, I did attempt to use it later but I couldn't get it to work since it had problems with the requirements for whatever reason, would that branch have contained a fix for this?

@alexsieusahai
Copy link

I want to take a crack at this; what would I need to know beforehand for ds and algs to understand the project beyond ast?

@rocky
Copy link
Owner

rocky commented Jul 11, 2018

@alexsieusahai I have outlined what I think you need to know in https://github.com/rocky/python-uncompyle6/wiki/Adding-a-tree-transformation-phase-to-uncompyle6 .

That has a link to other information, and generally the wiki has some information regarding how uncompyle6 works.

I'll open a separate issue for tracking discussions in the overall phase that is needed.

@rocky
Copy link
Owner

rocky commented Jun 23, 2019

Thanks to the efforts of @x0ret this is now addressed in e96498e.

Work has also been started on a tree transformation phase in the decompyle3 project to be able to organize the code better, make this more understandable (at least to me) and be able to support things like this better in the future.

@rocky rocky closed this as completed Jun 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants