jinx/python-uncompyle6
1
Fork 0
mirror of https://github.com/rocky/python-uncompyle6.git synced 2025-08-03 00:45:53 +08:00
Code Issues Packages Projects Releases Wiki Activity

What's up with 3.6

Browse Source
This commit is contained in:
rocky
2018-01-19 22:16:53 -05:00
parent 8194595ec9
commit 0c670f2f9e
1 changed files with 9 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
README.rst
View File

@@ -170,11 +170,15 @@ interpreter for versions 1.5, 1.6, and 2.0.
In the Python 3 series, Python support is is strongest around 3.4 or In the Python 3 series, Python support is is strongest around 3.4 or
3.3 and drops off as you move further away from those versions. Python 3.3 and drops off as you move further away from those versions. Python
3.6 changes things drastically by using word codes rather than byte 3.6 changes things drastically by using word codes rather than byte
codes. That has been addressed, but then it also changes function call codes. As a result, the jump offset field in a jump instruction
opcodes and its semantics and has more problems with control flow than argument has been reduced. This makes the `EXTENDED_ARG` instructions
3.5 has. Between Python 3.5, 3.6 and 3.7 there have been major changes are now more prevalent in jump instruction; previously they had been
to the `MAKE_FUNCTION` and `CALL_FUNCTION` instructions. Those are rare. Perhaps to compensate for the additional `EXTENDED_ARG`
not handled yet. instructions, additional jump optimization has been added. So in sum
handling control flow by ad hoc means as is currently done is worse.
Also, between Python 3.5, 3.6 and 3.7 there have been major changes to the
`MAKE_FUNCTION` and `CALL_FUNCTION` instructions.
Currently not all Python magic numbers are supported. Specifically in Currently not all Python magic numbers are supported. Specifically in
some versions of Python, notably Python 3.6, the magic number has some versions of Python, notably Python 3.6, the magic number has