Poor if statement formatting with Python 2.4 decompilation

[pythonengineer]

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]

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]

@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]

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]

@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]

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]

@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]

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.