Option to not write file header about python-uncompyle6 HOT 6 CLOSED

Hello,

Seems easy enough to do. What is the motivation for this?

from python-uncompyle6.

from python-uncompyle6.

Ok. Thanks for the information. Right now performance if anything has gotten worse on 2.7 since we are more focused on accuracy and handling Python bytecode other than 2.7.

So if all you care about is decompiling 2.7 using a 2.7ish compiler, then I'd stick with wibiti's uncompyle6. (There have been a couple of bugs found in that like escaping triple-quoted strings, and handling complex number constants, some control flow and function prototypes, and handling if == precedence; but all of these tend to be arcane situations. Someone could probably take the code in uncompyle6 and back port it to wibiti uncompyle2.)

While doing some testing and comparing the outputs I have also found that this project adds quite a few redundant return statements, is that intended behavior?

While it isn't intended, it isn't unintended either. The code works simply by following grammar patterns it detects in the code. Possibly it is matching more return statements than the grammar used previously.

In both, there's a special case hack to check to see if the last statement is a return statement https://github.com/rocky/python-uncompyle6/blob/master/uncompyle6/semantics/pysource.py#L1959-L1963

This test probably used to come out True more often. If this is important to fix, find a small test case that exhibits the problem and file an issue for that.

Oh, and if you file a pull request for an option to disable outputting headers, this will probably get done sooner.

from python-uncompyle6.

Closed because of lack of interest. In fact, it might not be a bad idea to go the other way. Maybe I should add my name in the meta comments.

from python-uncompyle6.

Why don't you just leave it open as a feature request? You don't have to implement it but you can keep it tracked.

from python-uncompyle6.

Nah - Nothing4You ;-)

from python-uncompyle6.