From c7124ad9cab176c34663b4065f6ad2c084b1b55f Mon Sep 17 00:00:00 2001 From: rocky Date: Thu, 4 Jul 2019 10:01:36 -0400 Subject: [PATCH] RsT :code: before backticks --- README.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.rst b/README.rst index 3a2172df..3195294e 100644 --- a/README.rst +++ b/README.rst @@ -134,7 +134,7 @@ could be compared with the original bytecode. However as Python's code generation got better, this no longer was feasible. If you want Python syntax verification of the correctness of the -decompilation process, add the `--syntax-verify` option. However since +decompilation process, add the :code:`--syntax-verify` option. However since Python syntax changes, you should use this option if the bytecode is the right bytecode for the Python interpreter that will be checking the syntax. @@ -148,7 +148,7 @@ available give stronger verification: those programs that when run test themselves. Our test suite includes these. And Python comes with another a set of programs like this: its test -suite for the standard library. We have some code in `test/stdlib` to +suite for the standard library. We have some code in :code:`test/stdlib` to facilitate this kind of checking too. Known Bugs/Restrictions @@ -179,15 +179,15 @@ In the Python 3 series, Python support is is strongest around 3.4 or 3.0 is weird in that it in some ways resembles 2.6 more than it does 3.1 or 2.7. Python 3.6 changes things drastically by using word codes rather than byte codes. As a result, the jump offset field in a jump -instruction argument has been reduced. This makes the `EXTENDED_ARG` +instruction argument has been reduced. This makes the :code:`EXTENDED_ARG` instructions are now more prevalent in jump instruction; previously they had been rare. Perhaps to compensate for the additional -`EXTENDED_ARG` instructions, additional jump optimization has been +:code:`EXTENDED_ARG` instructions, additional jump optimization has been added. So in sum handling control flow by ad hoc means as is currently done is worse. Between Python 3.5, 3.6 and 3.7 there have been major changes to the -`MAKE_FUNCTION` and `CALL_FUNCTION` instructions. +:code:`MAKE_FUNCTION` and :code:`CALL_FUNCTION` instructions. Currently not all Python magic numbers are supported. Specifically in some versions of Python, notably Python 3.6, the magic number has @@ -219,7 +219,7 @@ See Also * https://github.com/zrax/pycdc : purports to support all versions of Python. It is written in C++ and is most accurate for Python versions around 2.7 and 3.3 when the code was more actively developed. Accuracy for more recent versions of Python 3 and early versions of Python are especially lacking. See its `issue tracker `_ for details. Currently lightly maintained. * https://code.google.com/archive/p/unpyc3/ : supports Python 3.2 only. The above projects use a different decompiling technique than what is used here. Currently unmaintained. * https://github.com/figment/unpyc3/ : fork of above, but supports Python 3.3 only. Includes some fixes like supporting function annotations. Currently unmaintained. -* https://github.com/wibiti/uncompyle2 : supports Python 2.7 only, but does that fairly well. There are situations where `uncompyle6` results are incorrect while `uncompyle2` results are not, but more often uncompyle6 is correct when uncompyle2 is not. Because `uncompyle6` adheres to accuracy over idiomatic Python, `uncompyle2` can produce more natural-looking code when it is correct. Currently `uncompyle2` is lightly maintained. See its issue `tracker `_ for more details +* https://github.com/wibiti/uncompyle2 : supports Python 2.7 only, but does that fairly well. There are situations where :code:`uncompyle6` results are incorrect while :code:`uncompyle2` results are not, but more often uncompyle6 is correct when uncompyle2 is not. Because :code:`uncompyle6` adheres to accuracy over idiomatic Python, :code:`uncompyle2` can produce more natural-looking code when it is correct. Currently :code:`uncompyle2` is lightly maintained. See its issue `tracker `_ for more details * `How to report a bug `_ * The HISTORY_ file. * https://github.com/rocky/python-xdis : Cross Python version disassembler