Any way to have line numbers match the py file?

[cool-RR]

I want to use uncompyle6 to take a pyo file and try to restore the py file that it was made from. Any way to have the line numbers match? i.e. if someone looks at line 1234 in the uncompyle6 output, it'll be the same line as line 1234 in the original Python file?

[rocky]

The results may not be as close as you think because uncompyle6 doesn't have that much flexibility ways it can reformat things. For example, if you write:

  if x: return
  if y: return

uncompyle6 will get behind and until there are comments and blank lines to get back the slack it will be behind. And statements up to getting the required number of comments and blank lines will be behind.

So if you are willing to to put up with best effort then I guess this can be done.

Personally, I don't feel compelled to add this. But I had started this idea in uncompyle6/semantics/aligner.py, so that might be used as a starting point.

[cool-RR]

Thanks for your answer. I'm ignorant about how uncompyle6 so I'm just gonna say my thoughts, and if they don't make sense, feel free to ignore them. I know that when I'm getting a traceback for an exception in a Python program, it can tell me for each level in the stack, the line number the interpreter was on, even if the original py files are not available and it's running from pyo files. This leads me to believe that the information about which code corresponds to which line number is there. Do you think it's possible to use this information to get an accurate alignment of code lines? (The traceback scenario is my use case, I want to show the code lines in a traceback even when the py files aren't available.)

…

On Wed, Oct 25, 2017 at 2:38 AM, R. Bernstein ***@***.***> wrote: The results may not be as close as you think because uncompyle6 doesn't have that much flexibility ways it can reformat things. For example, if you write: if x: return if y: return uncompyle6 will get behind and until there are comments and blank lines to get back the slack it will be behind. And statements up to getting the required number of comments and blank lines will be behind. So if you are willing to to put up with best effort then I guess this can be done. Personally, I don't feel compelled to add this. But I had started this idea in uncompyle6/semantics/aligner.py <https://github.com/rocky/python-uncompyle6/blob/master/uncompyle6/semantics/aligner.py> that might be used as a starting point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#133 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADdynF_917dbazoQ1HYtCBNN6Amycy1ks5svnUGgaJpZM4QEnxd> .

[rocky]

While it is perfectly okay to start off ignorant (we all do), that doesn't excuse remaining so when given pointers for where to look.

As it says in the README.rst, this is why I got interested in this program, and uncompyle6 has been extended specifically for such purposes. So as it suggests, try out the trepan debuggers and the deparse command that it provides.

And look at http://rocky.github.io/NYC-Hackntell/#/ for an overview of what's going on. If you hit "s" you'll see the text of the slide.

I think it perfectly fine to list the line number without having to adjust the code formatting.

Down the line I will incorporate this as a mode available in the debugger's backtrace command, or in showing a frame.

However it would be nice to have someone volunteer to wrote say a package that models the the Python traceback module but gives this additional information. Are you up for it?

[cool-RR]

Thanks for the info! I'll check these out.

…

On Wed, Oct 25, 2017 at 1:13 PM, R. Bernstein ***@***.***> wrote: While it is perfectly okay to start off ignorant, that doesn't excuse remaining so when given pointers for where to look. As it says in the README.rst <https://github.com/rocky/python-uncompyle6#why-this>, this is why I got interested in this program, and uncompyle6 has been extended specifically for such purposes. So as it suggests, try out the trepan debuggers and the "deparse" command that it provides. And look at http://rocky.github.io/NYC-Hackntell/#/ where I for an overview of what's going on. If you hit "s" you'll see the text of the slide. I think it perfectly fine to list the line number without having to adjust the code formatting. Down the line I will incorporate this as a mode available in the debugger's backtrace command, or in showing a frame. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#133 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADdymjQbwDuscwxoe_vOwgs_qsK9U_tks5svwnDgaJpZM4QEnxd> .

[rocky]

Had another way of tackling this. Suppose uncompyle6 emitted in some sort of standard and easily parseable form, the source-code line numbers. Then another program could just read the python along with the comments and do whatever needs to be done to make that be true. And in those cases where it can't be done because the formatted program is behind where a nicely-formatted python program would be, it could just keep in those line comments.