Open JorianWoltjer opened 8 months ago
This is a bug in the print action routines (probably uncompyle6/semantics/gencomp.py) that take the AST produced and format and print the results. You can see the trees that get created by adding the -T
option to uncompyle6
.
A like kind of thing that happens is that the wrong child of a node is looked at in the generation routine.
This works in decompyle3, so one fix would be to backport code from there here.
Are you up for fixing this bug?
Thanks for the comment, I had not seen decompyle3 before and it does seem to work there! I'll try switching to that repository as I am working on Python 3.8.
I'm personally not up to the task of fixing it, especially now that I have a clean workaround, but maybe a backport can happen one day indeed.
One of the problems when decompile in list Comprehension and result is : parents = (lambda .0: [ Nodes.getParent(x) for x in .0 ])(nodes) and In some cases, it outputs an empty file In one case, a 60KB file became 120MB.had repeated in python 3.7 and decompyle6
@mosadegh22 file a proper bug report in decompyle3 and I might investigate when I am able.
Description
List comprehensions inside of a lambda print a single
[
bracket instead of the list comprehension, resulting in invalid syntax.How to Reproduce
The following is a simple list comprehension in a lambda function:
Stored in a file called
poc.py
, it can be compiled into a.pyc
file with the following commands:It decompiles to the following code on the latest 3.9.1 version:
This happens while a regular function using
def
containing a list comprehension does work perfectly:Expected behavior
Write the whole list comprehension just like a function using
def
would. This would be the expected output for the example above:Environment
Workarounds
Ignore the missing list comprehension code in the output, because it continues to print the code after it. This won't make the code inside the list comprehension visible though.