Fix const list for python 2.7 bytecode with uncompyle6 on python 3

[wangym5106]

Example:

a = ['a', 'b', 'c', 'd', 'e']

Decompiled result:

# uncompyle6 version 3.9.3
# Python bytecode version base 2.7 (62211)
# Decompiled from: Python 3.12.10 (tags/v3.12.10:0cc8128, Apr  8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]     
# Embedded file name: /cwd/test.py
# Compiled at: 2025-11-21 19:04:42
a = [
 0, 1, 2, 3, 4]

The issue seems caused by 8a1fd7e and 9fd139a , removed logic for Python 2
This PR recovers the logic and fix the issue

[rocky]

This is currently not a problem in the current uncompyle6 master. Note, however, that due to an API change in xdis, you'll also need the master branch of xdis to use it.

$ uncompyle6 list-const-2.7.pyc
# uncompyle6 version 3.9.3
# Python bytecode version base 2.7 (62211)
# Decompiled from: Python 2.7.18 (default, Feb 22 2021, 20:11:26) 
# [GCC 9.3.0]
# Embedded file name: list-const.py
# Compiled at: 2025-11-25 03:22:40
a = [
 'a', 'b', 'c', 'd', 'e']
return
('\n# okay decompiling', 'list-const-2.7.pyc')

As for the redundant return, that is a different problem.

[wangym5106]

@rocky That's weird. I use uncompyle6 master and xdis master , the issue still exist.

# uncompyle6 version 3.9.4.dev0
# Python bytecode version base 2.7 (62211)
#   Decompiled from: Python 3.12.10 (tags/v3.12.10:0cc8128, Apr  8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]
# Embedded file name: /cwd/test.py
# Compiled at: 2025-11-25 16:49:49
test = [
 0, 1, 2, 3, 4, 5]

My environment:

Python 3.12.10 on Windows 11
uncompyle6 and xdis : latest master branch
target bytecode compiled on Python 2.7.18

I'm using uncompyle6 on Python 3.12 to decompile Python 2.7 pyc, maybe that's the reason it behaves different?

[wangym5106]

Yes it's working on Python 2 but not on Python 3.
Checked diff between master and python-2.4-to-2.7 there is indeed a different attr and pattr https://github.com/rocky/python-uncompyle6/compare/master..python-2.4-to-2.7#diff-012a3cac0960f03d1d0e169001c4401750c08dd7a1c9ae0f273d358f14179d76L281

[rocky]

@rocky That's weird. I use uncompyle6 master and xdis master , the issue still exist.

# uncompyle6 version 3.9.4.dev0
# Python bytecode version base 2.7 (62211)
#   Decompiled from: Python 3.12.10 (tags/v3.12.10:0cc8128, Apr  8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)]
# Embedded file name: /cwd/test.py
# Compiled at: 2025-11-25 16:49:49
test = [
 0, 1, 2, 3, 4, 5]

My environment:

Python 3.12.10 on Windows 11
uncompyle6 and xdis : latest master branch
target bytecode compiled on Python 2.7.18

I'm using uncompyle6 on Python 3.12 to decompile Python 2.7 pyc, maybe that's the reason it behaves different?

Thanks for the information. I will look at this when I get a chance.

[rocky]

I have a feeling this still might be an xdis bug. That package is supposed to make doing this stuff easier and uniform, so version tests should not be needed. But again, I don't have time right now to investigate.

[rocky]

With a little more investigation, here is what I am seeing. LOAD_CONST is of optype "constant opcode" (which means its opcode value is found in the constants table. That information doesn't seem to be propagated in optype and it should also get propagated into the pseudo token's "ADD_VALUE" field. And then based on that (not the Python version) should uncompyle6 be able figure out what datatype the numeric operand is.

I realize this may seem a bit detailed and picayune, but my experience is that to cover all kinds of bytecode, separating concerns of what goes where helps in the long run.

[rocky]

@wangym5106, please look at #523 and let me know if this fixes the problem while not breaking other things.