Remove setuptools pin

Change copyright year to 2018

.circleci/config.yml

@@ -16,7 +16,7 @@ jobs:
     # To see the list of pre-built images that CircleCI provides for most common languages see
     # https://circleci.com/docs/2.0/circleci-images/
     docker:
-      - image: circleci/python:3.6.9
+      - image: circleci/python:3.8
     steps:
       # Machine Setup
       #   If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
@@ -29,7 +29,8 @@ jobs:
       # This is based on your 1.0 configuration file or project settings
       - run:
           working_directory: ~/rocky/python-uncompyle6
-        command: pip install --user virtualenv && pip install --user nose && pip install --user pep8
+          command: pip install --user virtualenv && pip install --user nose && pip install
+            --user pep8
       # Dependencies
       #   This would typically go in either a build or a build-and-test job when using workflows
       # Restore the dependency cache
@@ -41,10 +42,10 @@ jobs:
 
       - run:
           command: | # Use pip to install dependengcies
-          pip install --user --upgrade setuptools
-          # Until the next release
-          pip install git+https://github.com/rocky/python-xdis#egg=xdis
+            sudo pip install --user --upgrade setuptools
             pip install --user -e .
+            # Not sure why "pip install -e" doesn't work above
+            # pip install click spark-parser xdis
             pip install --user -r requirements-dev.txt
 
       # Save dependency cache
@@ -63,7 +64,7 @@ jobs:
       # Test
       #   This would typically be a build job when using workflows, possibly combined with build
       # This is based on your 1.0 configuration file or project settings
-    - run: sudo python ./setup.py develop && make check-3.6
+      - run: sudo pip install -e . && make check-3.6
       - run: cd ./test/stdlib && bash ./runtests.sh 'test_[p-z]*.py'
       # Teardown
       #   If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each
@@ -75,3 +76,5 @@ jobs:
           path: /tmp/circleci-artifacts
       - store_artifacts:
           path: /tmp/circleci-test-results
+    # The resource_class feature allows configuring CPU and RAM resources for each job. Different resource classes are available for different executors. https://circleci.com/docs/2.0/configuration-reference/#resourceclass
+    resource_class: large

.github/FUNDING.yml

@@ -6,7 +6,7 @@ open_collective: # Replace with a single Open Collective username
 ko_fi: # Replace with a single Ko-fi username
 tidelift: # Replace with a single Tidelift platform-name/package-name e.g., npm/babel
 community_bridge: # Replace with a single Community Bridge project-name e.g., cloud-foundry
-liberapay: # Replace with a single Liberapay username
+liberapay: rocky
 issuehunt: # Replace with a single IssueHunt username
 otechie: # Replace with a single Otechie username
 custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']

.github/ISSUE_TEMPLATE/bug-report.md

@@ -7,14 +7,19 @@ about: Tell us about uncompyle6 bugs
 <!-- __Note:__ If you are using this program to do something illegal - don't.
 The issue may be flagged to make it easier for those looking for illegal activity.
 
-Bugs are not for asking questions about a problem you
+If you are reporting a bug in decompilation, it will probably not be acted upon
+unless it is narrowed to a small example. You may have to do some work remove
+extraneous code from the source example. Most bugs can be expressed in 30 lines of
+code.
+
+Issues are not for asking questions about a problem you
 are trying to solve that involve the use of uncompyle6 along the way,
 although I may be more tolerant of this if you sponsor the project.
 
 Bugs are also not for general or novice kind help on how to install
-this Python program in your environment in the way you would like to
-have it set up, or how to interpret a Python traceback e.g. that winds
-up saying Python X.Y.Z is not supported.
+this Python program and its dependencies in your environment, or in
+the way you would like to have it set up, or how to interpret a Python
+traceback e.g. that winds up saying Python X.Y.Z is not supported.
 
 For these kinds of things, you will save yourself time by asking
 instead on forums like StackOverflow that are geared to helping people
@@ -50,8 +55,9 @@ Prerequisites/Caveats
 
 * Make sure the bytecode you have can be disassembled with a
   disassembler and produces valid results.
+* Try to make the bytecode that exhibits a bug as small as possible.
 * Don't put bytecode and corresponding source code on any service that
-  requires registration to download.
+  requires registration to download. Instead attach it as a zip file.
 * When you open a bug report there is no privacy. If you need privacy, then
   contact me by email and explain who you are and the need for privacy.
   But be mindful that you may be asked to sponsor the project for the
@@ -80,7 +86,7 @@ $ uncompyle6 <command-line-options>
 $
 ```
 
-Provide links to the Python bytecode. For example, you can create a
+Attach a zip file to the Python bytecode or a
 gist with the information. If you have the correct source code, you
 can add that too.
 
@@ -107,6 +113,7 @@ If this is too long, then try narrowing the problem to something short.
 Please modify for your setup
 
 - Uncompyle6 version: output from  `uncompyle6 --version` or `pip show uncompyle6`
+- xdis version: output from `pydisasm --version` or or `pip show xdis`
 - Python version for the version of Python the byte-compiled the file: `python -c "import sys; print(sys.version)"` where `python` is the correct CPython or PyPy binary.
 - OS and Version: [e.g. Ubuntu bionic]
 
@@ -118,7 +125,11 @@ Please modify for your setup
 
 ## Priority
 
-<!-- If this is blocking some important activity let us know what activity it blocks. -->
+<!-- If this is important for a particular public good state that here.
+     If this is blocking some important activity let us know what activity it blocks.
+
+	 Otherwise, we'll assume this has the lowest priority in addressing.
+	 -->
 
 ## Additional Context
 

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: False

.github/workflows/osx.yml

@@ -12,7 +12,7 @@ jobs:
     strategy:
       matrix:
         os: [macOS]
-        python-version: [3.7, 3.8]
+        python-version: [3.8]
     steps:
     - uses: actions/checkout@v2
     - name: Set up Python ${{ matrix.python-version }}
@@ -22,9 +22,9 @@ jobs:
     - name: Install dependencies
       run: |
         python -m pip install --upgrade pip
-        # Until the next xdis release
-        pip install git+https://github.com/rocky/python-xdis#egg=xdis
         pip install -e .
+        # Not sure why "pip install -e" doesn't work above
+        # pip install click spark-parser xdis
         pip install -r requirements-dev.txt
     - name: Test uncompyle6
       run: |

.github/workflows/ubuntu.yml

@@ -11,7 +11,7 @@ jobs:
     runs-on: ubuntu-latest
     strategy:
       matrix:
-        python-version: [3.7, 3.8]
+        python-version: [3.8]
     steps:
     - uses: actions/checkout@v2
     - name: Set up Python ${{ matrix.python-version }}
@@ -21,9 +21,8 @@ jobs:
     - name: Install dependencies
       run: |
         python -m pip install --upgrade pip
-        # Until the next xdis release
-        pip install git+https://github.com/rocky/python-xdis#egg=xdis
         pip install -e .
+        # pip install click spark-parser xdis
         pip install -r requirements-dev.txt
     - name: Test uncompyle6
       run: |

.github/workflows/windows.yml

@@ -12,7 +12,7 @@ jobs:
     strategy:
       matrix:
         os: [windows]
-        python-version: [3.7, 3.8]
+        python-version: [3.8]
     steps:
     - uses: actions/checkout@v2
     - name: Set up Python ${{ matrix.python-version }}
@@ -22,9 +22,9 @@ jobs:
     - name: Install dependencies
       run: |
         python -m pip install --upgrade pip
-        # Until the next xdis release
-        pip install git+https://github.com/rocky/python-xdis#egg=xdis
         pip install -e .
+        # Not sure why "pip install -e" doesn't work above
+        # pip install click spark-parser xdis
         pip install -r requirements-dev.txt
     - name: Test uncompyle6
       run: |

.gitignore

@@ -2,6 +2,7 @@
 *.pyo
 *_dis
 *~
+.mypy_cache
 /.cache
 /.eggs
 /.hypothesis
@@ -10,16 +11,17 @@
 /.pytest_cache
 /.python-version
 /.tox
-.mypy_cache
 /.venv*
 /README
 /__pkginfo__.pyc
 /dist
 /how-to-make-a-release.txt
 /nose-*.egg
+/pycharm-venv
 /tmp
 /uncompyle6.egg-info
 /unpyc
+/venv
 ChangeLog
 __pycache__
 build

.pre-commit-config.yaml

@@ -0,0 +1,22 @@
+default_language_version:
+  python: python
+repos:
+-   repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v4.5.0
+    hooks:
+    - id: check-merge-conflict
+    - id: debug-statements
+      stages: [pre-commit]
+    - id: end-of-file-fixer
+      stages: [pre-commit]
+-   repo: https://github.com/pycqa/isort
+    rev: 5.13.2
+    hooks:
+      - id: isort
+        stages: [pre-commit]
+-   repo: https://github.com/psf/black
+    rev: 23.12.1
+    hooks:
+    - id: black
+      language_version: python3
+      stages: [pre-commit]

HISTORY.md

@@ -7,7 +7,7 @@ In the interest of shortening what is written here, I am going to start where we
 For the earlier history up to 2006 and the code up until Python 2.4, which I find interesting, look at that link.
 
 Sometime around 2014 was the dawn of ["uncompyle" and PyPI](https://pypi.python.org/pypi/uncompyle/1.1) — the era of
-public version control. Dan Pascu's code although not public used [darcs](http://darcs.net/) for version control. I converted the darcs to to git and put this at [decompyle-2.4](https://github.com/rocky/decompile-2.4).
+public version control. Dan Pascu's code although not public used [darcs](http://darcs.net/) for version control. I converted the darcs repository to git and put this at [decompyle-2.4](https://github.com/rocky/decompile-2.4).
 
 # uncompyle, unpyc
 
@@ -17,7 +17,7 @@ The project exists not only on [github](https://github.com/gstarnberger/uncompyl
 [bitbucket](https://bitbucket.org/gstarnberger/uncompyle) and later the defunct [google
 code](https://code.google.com/archive/p/unpyc/) under the name _unpyc_. The git/svn history goes back to 2009. Somewhere in there the name was changed from "decompyle" to "unpyc" by Keknehv, and then to "uncompyle" by Guenther Starnberger.
 
-The name Thomas Grainger isn't found in (m)any of the commits in the several years of active development. First Keknehv worked on this up to Python 2.5 or so while acceping Python bytecode back to 2.0 or so. Then "hamled" made a few commits earler on, while Eike Siewertsen made a few commits later on. But mostly "wibiti", and Guenther Starnberger got the code to where uncompyle2 was around 2012.
+The name Thomas Grainger isn't found in (m)any of the commits in the several years of active development. First Keknehv worked on this up to Python 2.5 or so while accepting Python bytecode back to 2.0 or so. Then "hamled" made a few commits earlier on, while Eike Siewertsen made a few commits later on. But mostly "wibiti", and Guenther Starnberger got the code to where uncompyle2 was around 2012.
 
 While John Aycock and Hartmut Goebel were well versed in compiler technology, those that have come afterwards don't seem to have been as facile in it.  Furthermore, documentation or guidance on how the decompiler code worked, comparison to a conventional compiler pipeline, how to add new constructs, or debug grammars was weak. Some of the grammar tracing and error reporting was a bit weak as well.
 
@@ -38,7 +38,7 @@ I started working on this late 2015, mostly to add fragment support. In that, I
 * this project - grammar and semantic actions for decompiling
   ([uncompyle6](https://pypi.python.org/pypi/uncompyle6)).
 
- `uncompyle6`, abandons the idea found in some 2.7 version of `uncompyle` that support Python 2.6 and 2.5 by trying to rewite opcodes at the bytecode level.
+ `uncompyle6`, abandons the idea found in some 2.7 version of `uncompyle` that support Python 2.6 and 2.5 by trying to rewrite opcodes at the bytecode level.
 
 Having a grammar per Python version is simpler to maintain, cleaner and it scales indefinitely.
 
@@ -68,13 +68,13 @@ project is largely by Michael Hansen and Darryl Pogue. If they supported getting
 
 # So you want to write a decompiler for Python?
 
-If you think, as I am sure will happen in the future, "hey, I can just write a decompiler from scratch and not have to deal with all all of the complexity in uncompyle6", think again. What is likely to happen is that you'll get at best a 90% solution working for a single Python release that will be obsolete in about a year, and more obsolete each subsequent year.
+If you think, as I am sure will happen in the future, "hey, I can just write a decompiler from scratch and not have to deal with all of the complexity in uncompyle6", think again. What is likely to happen is that you'll get at best a 90% solution working for a single Python release that will be obsolete in about a year, and more obsolete each subsequent year.
 
 Writing a decompiler for Python gets harder as it Python progresses. Writing decompiler for Python 3.7 isn't as easy as it was for Python 2.2. For one thing, now that Python has a well-established AST, that opens another interface by which code can be improved.
 
 In Python 3.10 I am seeing (for the first time?) bytecode getting moved around so that it is no longer the case that line numbers have to be strictly increasing as bytecode offsets increase. And I am seeing dead code appear as well.
 
-That said, if you still feel you want to write a single version decompiler, look at the test cases in this project and talk to me. I may have some ideas that I haven't made public yet. See also what I've wrtten about the on how this code works and on [decompilation in dynamic runtime languages](http://rocky.github.io/Deparsing-Paper.pdf) in general.
+That said, if you still feel you want to write a single version decompiler, look at the test cases in this project and talk to me. I may have some ideas that I haven't made public yet. See also what I've written about the on how this code works and on [decompilation in dynamic runtime languages](http://rocky.github.io/Deparsing-Paper.pdf) in general.
 
 
 
@@ -82,8 +82,8 @@ That said, if you still feel you want to write a single version decompiler, look
 
 This project deparses using an Earley-algorithm parse. But in order to do this accurately, the process of tokenization is a bit more involved in the scanner. We don't just disassemble bytecode and use the opcode name. That aspect hasn't changed from the very first decompilers. However understanding _what_ information needs to be made explicit and what pseudo instructions to add that accomplish this has taken some time to understand.
 
-Earley-algorithm parsers have gotten negative press, most notably by the dragon book. Having used this a bit, I am convinced having a system that handles ambiguous grammars is the right thing to do and matches the problem well. Iin practice the speed of the parser isn't a problem when one understand what's up. And this has taken a little while to understand.
-Earley-algorim parsers for context free languages or languages that are to a large extent context free and tend to be linear and the grammar stears towards left recursive rules. There is a technique for improving LL right recursion, but our parser doesn't have that yet.
+Earley-algorithm parsers have gotten negative press, most notably by the dragon book. Having used this a bit, I am convinced having a system that handles ambiguous grammars is the right thing to do and matches the problem well. In practice the speed of the parser isn't a problem when one understand what's up. And this has taken a little while to understand.
+Earley-algorithm parsers for context free languages or languages that are to a large extent context free and tend to be linear and the grammar steers towards left recursive rules. There is a technique for improving LL right recursion, but our parser doesn't have that yet.
 
 The [decompiling paper](http://rocky.github.io/Deparsing-Paper.pdf) discusses these aspects in a more detail.
 

HOW-TO-REPORT-A-BUG.md

@@ -19,17 +19,17 @@
 
 TL;DR (too long; didn't read)
 
-* Don't do something illegal. And don't ask me to do something illegal or help you do something illegal
-* We already have an infinite supply of decompilation bugs that need fixing, and an automated mechanism for finding more. Decompilation bugs get addressed by easiness to fix and by whim. If you expect yours to be fixed ahead of those, you need to justify why.
+* Don't do something illegal. And don't ask me to do something illegal or help you do something illegal.
+* We already have an infinite supply of decompilation bugs that need fixing, and an automated mechanism for finding more. Decompilation bugs get addressed by easiness to fix and by whim. If you expect yours to be fixed ahead of those, you need to justify why. You can ask for a hand-assisted decompilation, but that is expensive and beyond what most are willing to spend. A $100 fee is needed just to look at the bytecode.
 * When asking for help, you may be asked for what you've tried on your own first. There are plenty of sources of information about this code.
-* If you are looking for *timely* help or support, well, that is typically known paid service. I don't really have a mechanism for that since I have a full-time job. But supporting the project is an approximation.
-* Submitting a bug or issue report that is likely to get acted upon may require a bit of effort on your part to make it easy for the problem solver. If you are not willing to do that, please don't waste our time. As indicated above, supporting the project will increase the likelihood of your issue getting noticed and acted upon.
+* Bugs get fixed, slowly. Sometimes on the order of months or years. If you are looking for *timely* help or support, that is typically known as a _paid_ service.
+* Submitting a bug or issue report that is likely to get acted upon may require a bit of effort on your part to make it easy for the problem solver. If you are not willing to do that, please don't waste your or our time. Bug report may be closed with about as much thought and care as apparent in the effort to create the bug. Supporting the project however, does increase the likelihood of your issue getting noticed and acted upon.
 
 # Ethics
 
-I do not condone using this program for unethical or illegal purposes. More detestable, at least to me, is asking for help to assist you in something that might not legitimate.
+Do not use this program for unethical or illegal purposes. More detestable, at least to me, is asking for help to assist you in something that might not legitimate.
 
-Don't use the issue tracker for such solicitations. To try to stave off illegitimate behavior, you should note that the issue tracker, the code, and bugs mentioned in that are in the open: there is no
+Don't use the issue tracker for such unethical or illegal solicitations. To try to stave off illegitimate behavior, you should note that the issue tracker, the code, and bugs mentioned in that are in the open: there is no
 confidentiality. You may be asked about the authorship or claimed ownership of the bytecode. If I think something is not quite right, I may label the issue questionable which may make the it easier those who are looking for illegal activity.
 
 
@@ -37,13 +37,13 @@ confidentiality. You may be asked about the authorship or claimed ownership of t
 
 For many open-source projects bugs where the expectation is that bugs are rare, reporting bugs in a *thoughtful* way can be helpful. See also [How to Ask Questions the Smart Way](http://www.catb.org/~esr/faqs/smart-questions.html).
 
-In this project though, most of the bug reports boil down to the something like: I have I am trying to reverse engineer some code that I am not the author/owner and that person doesn't want me to have access to. I am hitting a problem somewhere along the line which might have to do with decompilation, but it could be something else like how the bytecode was extracted, some problem in deliberately obfuscated code, or the use some kind of Python bytecode version that isn't supported by the decompiler.
+In this project though, most of the bug reports boil down to the something like: I am trying to reverse engineer some code that I am not the author/owner and that person doesn't want me to have access to. I am hitting a problem somewhere along the line which might have to do with decompilation. But it could be something else like how the bytecode was extracted, some problem in deliberately obfuscated code, or the use some kind of Python bytecode version that isn't supported by the decompiler. Gee this stuff is complicated, here's an open source project, so maybe someone there will help me figure stuff out.
 
-While you are free to report these, unless you sponsor the project, I may close them with about the same amount of effort spent that I think was used to open the report for them. And if you spent a considerable amount of time to create the bug report but didn't follow instructions given here and in the issue template, I am sorry in advance. Just go back, read, and follow instructions.
+While you are free to report bugs, unless you sponsor the project, I may close them with about the same amount of effort spent that I think was used to open the report for them. And if you spent a considerable amount of time to create the bug report but didn't follow instructions given here and in the issue template, I am sorry in advance. Just go back, read, and follow instructions.
 
 This project already has an infinite supply of bugs that have been narrowed to the most minimal form and where I have source code to compare against. And in the unlikely event this supply runs out, I have automated means for generating *another* infinite supply.
 
-In this project the task of justifying why addressing your bug is of use to the community, and why it should be prioritized over the others, is the bug reporter's responsibility.
+The task of justifying why addressing your bug is of use to the community, and why it should be prioritized over the others, is the bug reporter's responsibility.
 
 While in the abstract, I have no problem answering questions about how to read a Python traceback or install Python software, or trying to understand what is going wrong in your particular setup, I am not a paid support person and there other things I'd rather be doing with my limited volunteer time. So save us both time, effort, and aggravation: use other avenues like StackOverflow. Again, justifying why you should receive unpaid help is the help requester's responsibility.
 
@@ -74,7 +74,7 @@ obfuscation.
 Checking if bytecode is valid is pretty simple: disassemble the code.
 Python comes with a disassembly module called `dis`. A prerequisite
 module for this package, `xdis` has a cross-python version
-disassembler called `pydisasm`.
+disassembler called `pydisasm`. Using that with the `-F extended` option, generally provides a more comprehensive disassembly than is provided by other disassemblers.
 
 ## Semantic equivalence vs. exact source code
 

NEWS.md

@@ -1,3 +1,29 @@
+3.9.2: 2024-07-21
+=================
+
+- track xdis API changes
+- Bug fixes and lint
+
+3.9.1: 2024-05-15
+=================
+
+Lots of changes major changes. track xdis API has changes.
+
+Separate Phases more clearly:
+* disassembly
+* tokenization
+* parsing
+* abstracting to AST (more is done in newer projects)
+* printing
+
+Although we do not decompile bytecode greater than 3.8, code supports running from up to 3.12.
+
+Many bugs fixed.
+
+A lot of Linting and coding style modernization.
+
+Work done in preparation for Blackhat Asia 2024
+
 3.9.0: 2022-12-22
 =================
 
@@ -8,7 +34,7 @@
 * Correct 2.5-7 relative import formatting
 * Miscellaneous bug fixing
 * remove \n in lambda
-* Python 2.6 gramar cleanup
+* Python 2.6 grammar cleanup
 * Correct some Python 2.6 chain compare decompilation
 * Ensure no parenthesis subscript slices
 * Correct 2.x formatting "slice2" nonterminal
@@ -35,7 +61,7 @@
 ================
 
 * Fragment parsing was borked. This means deparsing in trepan2/trepan3k was broken
-* 3.7+: narrow precedence for call tatement
+* 3.7+: narrow precedence for call statement
 * del_stmt -> delete to better match Python AST
 * 3.8+ Add another `forelsestmt` (found only in a loop)
 * 3.8+ Add precedence on walrus operator
@@ -66,7 +92,7 @@ Mostly small miscellaneous bug fixes
 3.7.1: 2020-6-12 Fleetwood66
 ====================================================
 
-Released to pick up new xdis version which has fixes to read bytestings better on 3.x
+Released to pick up new xdis version which has fixes to read bytestrings better on 3.x
 
 * Handle 3.7+ "else" branch removal adAs seen in `_cmp()` of `python3.8/distutils/version.py` with optimization `-O2`
 * 3.6+ "with" and "with .. as" grammar improvements
@@ -89,10 +115,10 @@ More upheaval in xdis which we need to track here.
 3.6.6: 2020-4-20 Love in the time of Cholera
 ============================================
 
-The main reason for this release is an incompatablity bump in xdis which handles
+The main reason for this release is an incompatibility bump in xdis which handles
 3.7 SipHash better.
 
-* Go over "yield" as an expression precidence
+* Go over "yield" as an expression precedence
 * Some small alignment with code in decompyle3 for "or" and "and" was done
 
 
@@ -118,7 +144,7 @@ The main focus in this release was fix some of the more glaring problems creapt
 `uncompyle6` code is at a plateau where what is most needed is a code refactoring. In doing this, until everything refactored and replaced, decomplation may get worse.
 Therefore, this release largely serves as a checkpoint before more major upheaval.
 
-The upheaval, in  started last release, I believe the pinnicle was around c90ff51 which wasn't a release. I suppose I should tag that.
+The upheaval, in  started last release, I believe the pinnacle was around c90ff51 which wasn't a release. I suppose I should tag that.
 
 After c90ff5, I started down the road of redoing control flow in a more comprehensible, debuggable, and scalable way. See [The Control Flow Mess](https://github.com/rocky/python-uncompyle6/wiki/The-Control-Flow-Mess)
 
@@ -132,7 +158,7 @@ In the decompyle3 code, I've gone down the road making the grammar goal symbol b
 
 I cringe in thinking about how the code has lived for so long without noticing such a simple stupidity, and lapse of sufficient thought.
 
-Some stats from testing. The below give numbers of decompiled tests from Python's test suite which succesfully ran
+Some stats from testing. The below give numbers of decompiled tests from Python's test suite which successfully ran
 
 ```
    Version  test-suites passing
@@ -175,14 +201,14 @@ On the most recent Python versions I regularly decompile thousands of Python pro
 
 Does this mean the decompiler works perfectly? No. There are still a dozen or so failing programs, although the actual number of bugs is probably smaller though.
 
-However, in perparation of a more major refactoring of the parser grammar, this release was born.
+However, in preparation of a more major refactoring of the parser grammar, this release was born.
 
 In many cases, decompilation is better. But there are some cases where decompilation has gotten worse. For lack of time (and interest) 3.0 bytecode suffered a hit. Possibly some code in the 3.x range did too. In time and with cleaner refactored code, this will come back.
 
-Commit c90ff51 was a local maxiumum before, I started reworking the grammar to separate productions that were specific to loops versus those that are not in loops.
-In the middle of that I added another grammar simplication to remove singleton productions of the form `sstmts-> stmts`. These were always was a bit ugly, and complicated output.
+Commit c90ff51 was a local maximum before, I started reworking the grammar to separate productions that were specific to loops versus those that are not in loops.
+In the middle of that I added another grammar simplification to remove singleton productions of the form `sstmts-> stmts`. These were always was a bit ugly, and complicated output.
 
-At any rate if decompilation fails, you can try c90ff51. Or another decompiler. `unpyc37` is pretty good for 3.7. wibiti `uncompyle2` is great for 2.7. `pycdc` is mediocre for Python before 3.5 or so, and not that good for the most recent Python. Geerally these programs will give some sort of answer even if it isn't correct.
+At any rate if decompilation fails, you can try c90ff51. Or another decompiler. `unpyc37` is pretty good for 3.7. wibiti `uncompyle2` is great for 2.7. `pycdc` is mediocre for Python before 3.5 or so, and not that good for the most recent Python. Generally these programs will give some sort of answer even if it isn't correct.
 
 decompyle3 isn't that good for 3.7 and worse for 3.8, but right now it does things no other Python decompiler like `unpyc37` or `pycdc` does. For example, `decompyle3` handles variable annotations. As always, the issue trackers for the various programs will give you a sense for what needs to be done. For now, I've given up on reporting issues in the other decompilers because there are already enough issues reported, and they are just not getting fixed anyway.
 
@@ -213,7 +239,7 @@ indicate when an import contains a dotted import. Similarly, code for
 3.7 `import .. as ` is basically the same as `from .. import`, the
 only difference is the target of the name changes to an "alias" in the
 former. As a result, the disambiguation is now done on the semantic
-action side, rathero than in parsing grammar rules.
+action side, rather than in parsing grammar rules.
 
 Some small specific fixes:
 
@@ -246,13 +272,13 @@ versions better. This however comes with a big decompilation speed
 penalty. When we redo control flow this should go back to normal, but
 for now, accuracy is more important than speed.
 
-Another `assert` transform rule was added. Parser rules to distingish
+Another `assert` transform rule was added. Parser rules to distinguish
 `try/finally` in 3.8 were added and we are more stringent about what
 can be turned into an `assert`. There was some grammar cleanup here
 too.
 
 A number of small bugs were fixed, and some administrative changes to
-make `make check-short` really be short, but check more throughly what
+make `make check-short` really be short, but check more thoroughly what
 it checks. minimum xdis version needed was bumped to include in the
 newer 3.6-3.9 releases. See the `ChangeLog` for details.
 
@@ -261,7 +287,7 @@ newer 3.6-3.9 releases. See the `ChangeLog` for details.
 =============================
 
 The main focus in this release was more accurate decompilation especially
-for 3.7 and 3.8. However there are some improvments to Python 2.x as well,
+for 3.7 and 3.8. However there are some improvements to Python 2.x as well,
 including one of the long-standing problems of detecting the difference between
 `try ... ` and `try else ...`.
 
@@ -269,11 +295,11 @@ With this release we now rebase Python 3.7 on off of a 3.7 base; This
 is also as it is (now) in decompyle3.  This facilitates removing some of the
 cruft in control-flow detection in the 2.7 uncompyle2 base.
 
-Alas, decompilation speed for 3.7 on is greatly increased. Hopefull
+Alas, decompilation speed for 3.7 on is greatly increased. Hopefully
 this is temporary (cough, cough) until we can do a static control flow
 pass.
 
-Finally, runing in 3.9-dev is tolerated. We can disassemble, but no parse tables yet.
+Finally, running in 3.9-dev is tolerated. We can disassemble, but no parse tables yet.
 
 
 3.5.1 2019-11-17 JNC
@@ -566,7 +592,7 @@ function calls and definitions.
 - Misc pydisasm fixes
 - Weird comprehension bug seen via new loctraceback
 - Fix Python 3.5+ CALL_FUNCTION_VAR and BUILD_LIST_UNPACK in call; with this
-  we can can handle 3.5+ f(a, b, *c, *d, *e) now
+  we can handle 3.5+ f(a, b, *c, *d, *e) now
 
 2.15.1 2018-02-05
 =====================
@@ -661,7 +687,7 @@ Overall: better 3.6 decompiling and some much needed code refactoring and cleanu
 - Handle `EXTENDED_ARGS` better. While relevant to all Python versions it is most noticeable in
   version 3.6+ where in switching to wordcodes the size of operands has been reduced from 2^16
   to 2^8. `JUMP` instruction then often need EXTENDED_ARGS.
-- Refactor find_jump_targets() with via working of of instructions rather the bytecode array.
+- Refactor find_jump_targets() with via working of instructions rather the bytecode array.
 - use `--weak-verify` more and additional fuzzing on verify()
 - fragment parser now ignores errors in nested function definitions; an parameter was
   added to assist here. Ignoring errors may be okay because the fragment parser often just needs,

NEW_FEATURES.rst

@@ -171,7 +171,7 @@ Expanding decompiler availability to multiple Python Versions
 --------------------------------------------------------------
 
 Above we mention decompiling multiple versions of bytecode from a
-single Python interpreter. We we talk about having the decompiler
+single Python interpreter. We talk about having the decompiler
 runnable from multiple versions of Python, independent of the set of
 bytecode that the decompiler supports.
 
@@ -185,7 +185,7 @@ implemented correctly. These also make excellent programs to check
 whether a program has decompiled correctly.
 
 Aside from this, debugging can be easier as well. To assist
-understanding bytcode and single stepping it see `x-python
+understanding bytecode and single stepping it see `x-python
 <https://pypi.org/project/x-python/>`_ and the debugger for it
 `trepan-xpy <https://pypi.org/project/trepanxpy/>`_.
 

PKG-INFO

@@ -1,10 +1,355 @@
-Metadata-Version: 2.0
+Metadata-Version: 1.1
 Name: uncompyle6
-Version: 2.0.1
-Summary: Python byte-code to source-code converter
-Home-page: http://github.com/rocky/python-uncompyle6
-Author: Rocky
+Version: 3.9.1
+Summary: Python cross-version byte-code decompiler
+Home-page: https://github.com/rocky/python-uncompyle6/
+Author: Rocky Bernstein, Hartmut Goebel, John Aycock, and others
 Author-email: rb@dustyfeet.com
-License: MIT
-Description: UNKNOWN
+License: GPL3
+Description: |buildstatus|  |Pypi Installs| |Latest Version| |Supported Python Versions|
+        
+        |packagestatus|
+        
+        .. contents::
+        
+        uncompyle6
+        ==========
+        
+        A native Python cross-version decompiler and fragment decompiler.
+        The successor to decompyle, uncompyle, and uncompyle2.
+        
+        
+        Introduction
+        ------------
+        
+        *uncompyle6* translates Python bytecode back into equivalent Python
+        source code. It accepts bytecodes from Python version 1.0 to version
+        3.8, spanning over 24 years of Python releases. We include Dropbox's
+        Python 2.5 bytecode and some PyPy bytecodes.
+        
+        Why this?
+        ---------
+        
+        Ok, I'll say it: this software is amazing. It is more than your
+        normal hacky decompiler. Using compiler_ technology, the program
+        creates a parse tree of the program from the instructions; nodes at
+        the upper levels that look a little like what might come from a Python
+        AST. So we can really classify and understand what's going on in
+        sections of Python bytecode.
+        
+        Building on this, another thing that makes this different from other
+        CPython bytecode decompilers is the ability to deparse just
+        *fragments* of source code and give source-code information around a
+        given bytecode offset.
+        
+        I use the tree fragments to deparse fragments of code *at run time*
+        inside my trepan_ debuggers_. For that, bytecode offsets are recorded
+        and associated with fragments of the source code. This purpose,
+        although compatible with the original intention, is yet a little bit
+        different.  See this_ for more information.
+        
+        Python fragment deparsing given an instruction offset is useful in
+        showing stack traces and can be incorporated into any program that
+        wants to show a location in more detail than just a line number at
+        runtime.  This code can be also used when source-code information does
+        not exist and there is just bytecode. Again, my debuggers make use of
+        this.
+        
+        There were (and still are) a number of decompyle, uncompyle,
+        uncompyle2, uncompyle3 forks around. Many of them come basically from
+        the same code base, and (almost?) all of them are no longer actively
+        maintained. One was really good at decompiling Python 1.5-2.3, another
+        really good at Python 2.7, but that only. Another handles Python 3.2
+        only; another patched that and handled only 3.3.  You get the
+        idea. This code pulls all of these forks together and *moves
+        forward*. There is some serious refactoring and cleanup in this code
+        base over those old forks. Even more experimental refactoring is going
+        on in decompyle3_.
+        
+        This demonstrably does the best in decompiling Python across all
+        Python versions. And even when there is another project that only
+        provides decompilation for subset of Python versions, we generally do
+        demonstrably better for those as well.
+        
+        How can we tell? By taking Python bytecode that comes distributed with
+        that version of Python and decompiling these.  Among those that
+        successfully decompile, we can then make sure the resulting programs
+        are syntactically correct by running the Python interpreter for that
+        bytecode version.  Finally, in cases where the program has a test for
+        itself, we can run the check on the decompiled code.
+        
+        We use an automated processes to find bugs. In the issue trackers for
+        other decompilers, you will find a number of bugs we've found along
+        the way. Very few to none of them are fixed in the other decompilers.
+        
+        Requirements
+        ------------
+        
+        The code in the git repository can be run from Python 2.4 to the
+        latest Python version, with the exception of Python 3.0 through
+        3.2. Volunteers are welcome to address these deficiencies if there a
+        desire to do so.
+        
+        The way it does this though is by segregating consecutive Python versions into
+        git branches:
+        
+        master
+           Python 3.6 and up (uses type annotations)
+        python-3.3-to-3.5
+           Python 3.3 through 3.5 (Generic Python 3)
+        python-2.4
+           Python 2.4 through 2.7 (Generic Python 2)
+        
+        PyPy 3-2.4 and later works as well.
+        
+        The bytecode files it can read have been tested on Python
+        bytecodes from versions 1.4, 2.1-2.7, and 3.0-3.8 and later PyPy
+        versions.
+        
+        Installation
+        ------------
+        
+        You can install from PyPI using the name ``uncompyle6``::
+        
+            pip install uncompyle6
+        
+        
+        To install from source code, this project uses setup.py, so it follows the standard Python routine::
+        
+            $ pip install -e .  # set up to run from source tree
+        
+        or::
+        
+            $ python setup.py install # may need sudo
+        
+        A GNU Makefile is also provided so :code:`make install` (possibly as root or
+        sudo) will do the steps above.
+        
+        Running Tests
+        -------------
+        
+        ::
+        
+           make check
+        
+        A GNU makefile has been added to smooth over setting running the right
+        command, and running tests from fastest to slowest.
+        
+        If you have remake_ installed, you can see the list of all tasks
+        including tests via :code:`remake --tasks`
+        
+        
+        Usage
+        -----
+        
+        Run
+        
+        ::
+        
+        $ uncompyle6 *compiled-python-file-pyc-or-pyo*
+        
+        For usage help:
+        
+        ::
+        
+           $ uncompyle6 -h
+        
+        Verification
+        ------------
+        
+        In older versions of Python it was possible to verify bytecode by
+        decompiling bytecode, and then compiling using the Python interpreter
+        for that bytecode version. Having done this, the bytecode produced
+        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 :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.
+        
+        You can also cross compare the results with another version of
+        `uncompyle6` since there are sometimes regressions in decompiling
+        specific bytecode as the overall quality improves.
+        
+        For Python 3.7 and 3.8, the code in decompyle3_ is generally
+        better.
+        
+        Or try specific another python decompiler like uncompyle2_, unpyc37_,
+        or pycdc_.  Since the later two work differently, bugs here often
+        aren't in that, and vice versa.
+        
+        There is an interesting class of these programs that is readily
+        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 :code:`test/stdlib` to
+        facilitate this kind of checking too.
+        
+        Known Bugs/Restrictions
+        -----------------------
+        
+        The biggest known and possibly fixable (but hard) problem has to do
+        with handling control flow. (Python has probably the most diverse and
+        screwy set of compound statements I've ever seen; there
+        are "else" clauses on loops and try blocks that I suspect many
+        programmers don't know about.)
+        
+        All of the Python decompilers that I have looked at have problems
+        decompiling Python's control flow. In some cases we can detect an
+        erroneous decompilation and report that.
+        
+        Python support is pretty good for Python 2
+        
+        On the lower end of Python versions, decompilation seems pretty good although
+        we don't have any automated testing in place for Python's distributed tests.
+        Also, we don't have a Python interpreter for versions 1.6, and 2.0.
+        
+        In the Python 3 series, Python support is strongest around 3.4 or
+        3.3 and drops off as you move further away from those versions. Python
+        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 :code:`EXTENDED_ARG`
+        instructions are now more prevalent in jump instruction; previously
+        they had been rare.  Perhaps to compensate for the additional
+        :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, 3.7 there have been major changes to the
+        :code:`MAKE_FUNCTION` and :code:`CALL_FUNCTION` instructions.
+        
+        Python 3.8 removes :code:`SETUP_LOOP`, :code:`SETUP_EXCEPT`,
+        :code:`BREAK_LOOP`, and :code:`CONTINUE_LOOP`, instructions which may
+        make control-flow detection harder, lacking the more sophisticated
+        control-flow analysis that is planned. We'll see.
+        
+        Currently not all Python magic numbers are supported. Specifically in
+        some versions of Python, notably Python 3.6, the magic number has
+        changes several times within a version.
+        
+        **We support only released versions, not candidate versions.** Note
+        however that the magic of a released version is usually the same as
+        the *last* candidate version prior to release.
+        
+        There are also customized Python interpreters, notably Dropbox,
+        which use their own magic and encrypt bytecode. With the exception of
+        the Dropbox's old Python 2.5 interpreter this kind of thing is not
+        handled.
+        
+        We also don't handle PJOrion_ or otherwise obfuscated code. For
+        PJOrion try: PJOrion Deobfuscator_ to unscramble the bytecode to get
+        valid bytecode before trying this tool; pydecipher_ might help with that.
+        
+        This program can't decompile Microsoft Windows EXE files created by
+        Py2EXE_, although we can probably decompile the code after you extract
+        the bytecode properly. `Pydeinstaller <https://github.com/charles-dyfis-net/pydeinstaller>`_ may help with unpacking Pyinstaller bundlers.
+        
+        Handling pathologically long lists of expressions or statements is
+        slow. We don't handle Cython_ or MicroPython which don't use bytecode.
+        
+        There are numerous bugs in decompilation. And that's true for every
+        other CPython decompiler I have encountered, even the ones that
+        claimed to be "perfect" on some particular version like 2.4.
+        
+        As Python progresses decompilation also gets harder because the
+        compilation is more sophisticated and the language itself is more
+        sophisticated. I suspect that attempts there will be fewer ad-hoc
+        attempts like unpyc37_ (which is based on a 3.3 decompiler) simply
+        because it is harder to do so. The good news, at least from my
+        standpoint, is that I think I understand what's needed to address the
+        problems in a more robust way. But right now until such time as
+        project is better funded, I do not intend to make any serious effort
+        to support Python versions 3.8 or 3.9, including bugs that might come
+        in. I imagine at some point I may be interested in it.
+        
+        You can easily find bugs by running the tests against the standard
+        test suite that Python uses to check itself. At any given time, there are
+        dozens of known problems that are pretty well isolated and that could
+        be solved if one were to put in the time to do so. The problem is that
+        there aren't that many people who have been working on bug fixing.
+        
+        Some of the bugs in 3.7 and 3.8 are simply a matter of back-porting
+        the fixes in decompyle3. Volunteers are welcome to do so.
+        
+        You may run across a bug, that you want to report. Please do so after
+        reading `How to report a bug
+        <https://github.com/rocky/python-uncompyle6/blob/master/HOW-TO-REPORT-A-BUG.md>`_ and
+        follow the `instructions when opening an issue <https://github.com/rocky/python-uncompyle6/issues/new?assignees=&labels=&template=bug-report.md>`_.
+        
+        Be aware that it might not get my attention for a while. If you
+        sponsor or support the project in some way, I'll prioritize your
+        issues above the queue of other things I might be doing instead.
+        
+        See Also
+        --------
+        
+        * https://github.com/rocky/python-decompile3 : Much smaller and more modern code, focusing on 3.7 and 3.8. Changes in that will get migrated back here.
+        * 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 :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 <https://github.com/wibiti/uncompyle2/issues>`_ for more details.
+        * `How to report a bug <https://github.com/rocky/python-uncompyle6/blob/master/HOW-TO-REPORT-A-BUG.md>`_
+        * The HISTORY_ file.
+        * https://github.com/rocky/python-xdis : Cross Python version disassembler
+        * https://github.com/rocky/python-xasm : Cross Python version assembler
+        * https://github.com/rocky/python-uncompyle6/wiki : Wiki Documents which describe the code and aspects of it in more detail
+        * https://github.com/zrax/pycdc : The README for this C++ code says it aims to support all versions of Python. You can aim your slign shot for the moon too, but I doubt you are going to hit it. This code is best for Python versions around 2.7 and 3.3 when the code was initially developed. Accuracy for current versions of Python3 and early versions of Python is lacking. Without major effort, it is unlikely it can be made to support current Python 3. See its `issue tracker <https://github.com/zrax/pycdc/issues>`_ for details. Currently lightly maintained.
+        
+        
+        .. _Cython: https://en.wikipedia.org/wiki/Cython
+        .. _trepan: https://pypi.python.org/pypi/trepan3k
+        .. _compiler: https://github.com/rocky/python-uncompyle6/wiki/How-does-this-code-work%3F
+        .. _HISTORY: https://github.com/rocky/python-uncompyle6/blob/master/HISTORY.md
+        .. _report_bug: https://github.com/rocky/python-uncompyle6/blob/master/HOW-TO-REPORT-A-BUG.md
+        .. _debuggers: https://pypi.python.org/pypi/trepan3k
+        .. _remake: https://bashdb.sf.net/remake
+        .. _pycdc: https://github.com/zrax/pycdc
+        .. _decompyle3: https://github.com/rocky/python-decompile3
+        .. _uncompyle2: https://github.com/wibiti/uncompyle2
+        .. _unpyc37: https://github.com/andrew-tavera/unpyc37
+        .. _this: https://github.com/rocky/python-uncompyle6/wiki/Deparsing-technology-and-its-use-in-exact-location-reporting
+        .. |buildstatus| image:: https://travis-ci.org/rocky/python-uncompyle6.svg
+        		 :target: https://travis-ci.org/rocky/python-uncompyle6
+        .. |packagestatus| image:: https://repology.org/badge/vertical-allrepos/python:uncompyle6.svg
+        		 :target: https://repology.org/project/python:uncompyle6/versions
+        .. _PJOrion: http://www.koreanrandom.com/forum/topic/15280-pjorion-%D1%80%D0%B5%D0%B4%D0%B0%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F-%D0%B4%D0%B5%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F-%D0%BE%D0%B1%D1%84
+        .. _pydecipher: https://github.com/mitre/pydecipher
+        .. _Deobfuscator: https://github.com/extremecoders-re/PjOrion-Deobfuscator
+        .. _Py2EXE: https://en.wikipedia.org/wiki/Py2exe
+        .. |Supported Python Versions| image:: https://img.shields.io/pypi/pyversions/uncompyle6.svg
+        .. |Latest Version| image:: https://badge.fury.io/py/uncompyle6.svg
+        		 :target: https://badge.fury.io/py/uncompyle6
+        .. |Pypi Installs| image:: https://pepy.tech/badge/uncompyle6/month
+        
+        
 Platform: UNKNOWN
+Classifier: Development Status :: 5 - Production/Stable
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: GNU General Public License v3 (GPLv3)
+Classifier: Operating System :: OS Independent
+Classifier: Programming Language :: Python
+Classifier: Programming Language :: Python :: 2
+Classifier: Programming Language :: Python :: 2.4
+Classifier: Programming Language :: Python :: 2.5
+Classifier: Programming Language :: Python :: 2.6
+Classifier: Programming Language :: Python :: 2.7
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.0
+Classifier: Programming Language :: Python :: 3.1
+Classifier: Programming Language :: Python :: 3.2
+Classifier: Programming Language :: Python :: 3.3
+Classifier: Programming Language :: Python :: 3.4
+Classifier: Programming Language :: Python :: 3.5
+Classifier: Programming Language :: Python :: 3.6
+Classifier: Programming Language :: Python :: 3.7
+Classifier: Programming Language :: Python :: 3.8
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: Implementation :: PyPy
+Classifier: Topic :: Software Development :: Debuggers
+Classifier: Topic :: Software Development :: Libraries :: Python Modules

README.rst

@@ -10,6 +10,8 @@ uncompyle6
 A native Python cross-version decompiler and fragment decompiler.
 The successor to decompyle, uncompyle, and uncompyle2.
 
+I gave a talk on this at `BlackHat Asia 2024 <https://youtu.be/H-7ZNrpsV50?si=nOaixgYHr7RbILVS>`_.
+
 
 Introduction
 ------------
@@ -41,7 +43,7 @@ although compatible with the original intention, is yet a little bit
 different.  See this_ for more information.
 
 Python fragment deparsing given an instruction offset is useful in
-showing stack traces and can be encorporated into any program that
+showing stack traces and can be incorporated into any program that
 wants to show a location in more detail than just a line number at
 runtime.  This code can be also used when source-code information does
 not exist and there is just bytecode. Again, my debuggers make use of
@@ -161,8 +163,8 @@ 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.
 
-You can also cross compare the results with either another version of
-`uncompyle6` since there are are sometimes regressions in decompiling
+You can also cross compare the results with another version of
+*uncompyle6* since there are sometimes regressions in decompiling
 specific bytecode as the overall quality improves.
 
 For Python 3.7 and 3.8, the code in decompyle3_ is generally
@@ -199,7 +201,7 @@ On the lower end of Python versions, decompilation seems pretty good although
 we don't have any automated testing in place for Python's distributed tests.
 Also, we don't have a Python interpreter for versions 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 strongest around 3.4 or
 3.3 and drops off as you move further away from those versions. Python
 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
@@ -265,7 +267,7 @@ be solved if one were to put in the time to do so. The problem is that
 there aren't that many people who have been working on bug fixing.
 
 Some of the bugs in 3.7 and 3.8 are simply a matter of back-porting
-the fixes in decompyle3. Volunteers are welcome to do so.
+the fixes in *decompyle3*. Any volunteers?
 
 You may run across a bug, that you want to report. Please do so after
 reading `How to report a bug
@@ -274,11 +276,15 @@ follow the `instructions when opening an issue <https://github.com/rocky/python-
 
 Be aware that it might not get my attention for a while. If you
 sponsor or support the project in some way, I'll prioritize your
-issues above the queue of other things I might be doing instead.
+issues above the queue of other things I might be doing instead. In
+rare situtations, I can do a hand decompilation of bytecode for a fee.
+However this is expansive, usually beyond what most people are willing
+to spend.
 
 See Also
 --------
 
+* https://rocky.github.io/blackhat-asia-2024-additional/all-notes-print.html :  How to Read and Write a High-Level Bytecode Decompiler: ``uncompyle6`` ``decompyle3`` -- BlackHat 2024 Asia (`video <https://www.youtube.com/watch?v=NA77SFncppE>`_). A big thanks to the Organizers and Reviewers for letting me speak. This kind of thing encourages me to work on projects like this.
 * https://github.com/rocky/python-decompile3 : Much smaller and more modern code, focusing on 3.7 and 3.8. Changes in that will get migrated back here.
 * 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.
@@ -303,8 +309,8 @@ See Also
 .. _uncompyle2: https://github.com/wibiti/uncompyle2
 .. _unpyc37: https://github.com/andrew-tavera/unpyc37
 .. _this: https://github.com/rocky/python-uncompyle6/wiki/Deparsing-technology-and-its-use-in-exact-location-reporting
-.. |buildstatus| image:: https://travis-ci.org/rocky/python-uncompyle6.svg
-		 :target: https://travis-ci.org/rocky/python-uncompyle6
+.. |buildstatus| image:: https://circleci.com/gh/rocky/python-uncompyle6.svg?style=svg
+		 :target: https://app.circleci.com/pipelines/github/rocky/python-uncompyle6
 .. |packagestatus| image:: https://repology.org/badge/vertical-allrepos/python:uncompyle6.svg
 		 :target: https://repology.org/project/python:uncompyle6/versions
 .. _PJOrion: http://www.koreanrandom.com/forum/topic/15280-pjorion-%D1%80%D0%B5%D0%B4%D0%B0%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F-%D0%B4%D0%B5%D0%BA%D0%BE%D0%BC%D0%BF%D0%B8%D0%BB%D1%8F%D1%86%D0%B8%D1%8F-%D0%BE%D0%B1%D1%84

__pkginfo__.py

@@ -1,4 +1,4 @@
-# Copyright (C) 2018, 2020-2021 Rocky Bernstein <rocky@gnu.org>
+# Copyright (C) 2018, 2020-2021 2024 Rocky Bernstein <rocky@gnu.org>
 #
 #  This program is free software: you can redistribute it and/or modify
 #  it under the terms of the GNU General Public License as published by
@@ -32,9 +32,11 @@
 # 3.3            | pip     | 10.0.1       |
 # 3.4            | pip     | 19.1.1       |
 
+import os.path as osp
+
 # Things that change more often go here.
 copyright = """
-Copyright (C) 2015-2021 Rocky Bernstein <rb@dustyfeet.com>.
+Copyright (C) 2015-2021, 2024 Rocky Bernstein <rb@dustyfeet.com>.
 """
 
 classifiers = [
@@ -60,6 +62,8 @@ classifiers = [
     "Programming Language :: Python :: 3.8",
     "Programming Language :: Python :: 3.9",
     "Programming Language :: Python :: 3.10",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
     "Programming Language :: Python :: Implementation :: PyPy",
     "Topic :: Software Development :: Debuggers",
     "Topic :: Software Development :: Libraries :: Python Modules",
@@ -75,7 +79,7 @@ entry_points = {
     ]
 }
 ftp_url = None
-install_requires = ["spark-parser >= 1.8.9, < 1.9.0", "xdis >= 6.0.2, < 6.1.0"]
+install_requires = ["click", "spark-parser >= 1.8.9, < 1.9.2", "xdis >= 6.1.1, < 6.2.0"]
 
 license = "GPL3"
 mailing_list = "python-debugger@googlegroups.com"
@@ -88,21 +92,18 @@ web = "https://github.com/rocky/python-uncompyle6/"
 zip_safe = True
 
 
-import os.path
-
-
 def get_srcdir():
-    filename = os.path.normcase(os.path.dirname(os.path.abspath(__file__)))
-    return os.path.realpath(filename)
+    filename = osp.normcase(osp.dirname(osp.abspath(__file__)))
+    return osp.realpath(filename)
 
 
 srcdir = get_srcdir()
 
 
 def read(*rnames):
-    return open(os.path.join(srcdir, *rnames)).read()
+    return open(osp.join(srcdir, *rnames)).read()
 
 
-# Get info from files; set: long_description and __version__
+# Get info from files; set: long_description and VERSION
 long_description = read("README.rst") + "\n"
 exec(read("uncompyle6/version.py"))

admin-tools/.gitignore

@@ -0,0 +1 @@
+/.python-version

admin-tools/check-2.4-2.7-versions.sh

@@ -1,4 +1,6 @@
 #!/bin/bash
+# Run tests over all Python versions in branch python-2.4-2.7
+set -e
 function finish {
   cd $owd
 }
@@ -10,7 +12,9 @@ if ! source ./pyenv-2.4-2.7-versions ; then
     exit $?
 fi
 if ! source ./setup-python-2.4.sh ; then
-    exit $?
+    rc=$?
+    finish
+    exit $rc
 fi
 
 cd ..
@@ -21,7 +25,10 @@ for version in $PYVERSIONS; do
     fi
     make clean && python setup.py develop
     if ! make check ; then
+	finish
+	rc=$?
 	exit $?
     fi
     echo === $version ===
 done
+finish

admin-tools/check-3.0-3.2-versions.sh

@@ -0,0 +1,31 @@
+#!/bin/bash
+# Run tests over all Python versions in branch python-3.0-3.2
+set -e
+function finish {
+  cd $owd
+}
+
+owd=$(pwd)
+trap finish EXIT
+
+cd $(dirname ${BASH_SOURCE[0]})
+if ! source ./pyenv-3.0-3.2-versions ; then
+    exit $?
+fi
+if ! source ./setup-python-3.0.sh ; then
+    exit $?
+fi
+
+cd ..
+for version in $PYVERSIONS; do
+    echo --- $version ---
+    if ! pyenv local $version ; then
+	exit $?
+    fi
+    make clean && python setup.py develop
+    if ! make check ; then
+	exit $?
+    fi
+    echo === $version ===
+done
+finish

admin-tools/check-3.3-3.5-versions.sh

@@ -1,4 +1,6 @@
 #!/bin/bash
+# Run tests over all Python versions in branch python-3.3-3.5
+set -e
 function finish {
   cd $owd
 }
@@ -25,3 +27,4 @@ for version in $PYVERSIONS; do
     fi
     echo === $version ===
 done
+finish

admin-tools/checkout_common.sh

@@ -0,0 +1,21 @@
+# Common checkout routine
+export PATH=$HOME/.pyenv/bin/pyenv:$PATH
+bs=${BASH_SOURCE[0]}
+mydir=$(dirname $bs)
+fulldir=$(readlink -f $mydir)
+
+function setup_version {
+    local repo=$1
+    version=$2
+    echo Running setup $version on $repo ...
+    (cd ../$repo && . ./admin-tools/setup-${version}.sh)
+    return $?
+}
+
+function checkout_finish {
+    branch=$1
+    cd $uncompyle6_owd
+    git checkout $branch && pyenv local $PYTHON_VERSION && git pull
+    rc=$?
+    return $rc
+}

admin-tools/make-dist-2.4-2.7.sh

@@ -3,9 +3,9 @@ PACKAGE=uncompyle6
 
 # FIXME put some of the below in a common routine
 function finish {
-  cd $owd
+  cd $make_dist_uncompyle6_owd
 }
-owd=$(pwd)
+make_dist_uncompyle6_owd=$(pwd)
 trap finish EXIT
 
 cd $(dirname ${BASH_SOURCE[0]})
@@ -21,6 +21,11 @@ source $PACKAGE/version.py
 echo $__version__
 
 for pyversion in $PYVERSIONS; do
+    echo --- $pyversion ---
+    if [[ ${pyversion:0:4} == "pypy" ]] ; then
+	echo "$pyversion - PyPy does not get special packaging"
+	continue
+    fi
     if ! pyenv local $pyversion ; then
 	exit $?
     fi
@@ -41,3 +46,4 @@ tarball=dist/${PACKAGE}-${__version_}_-tar.gz
 if [[ -f $tarball ]]; then
     rm -v dist/${PACKAGE}-${__version__}-tar.gz
 fi
+finish

admin-tools/make-dist-3.0-3.2.sh

@@ -0,0 +1,49 @@
+#!/bin/bash
+PACKAGE=uncompyle6
+
+# FIXME put some of the below in a common routine
+function finish {
+  cd $uncompyle6_30_make_dist_owd
+}
+
+cd $(dirname ${BASH_SOURCE[0]})
+uncompyle6_30_make_dist_owd=$(pwd)
+trap finish EXIT
+
+if ! source ./pyenv-3.0-3.2-versions ; then
+    exit $?
+fi
+if ! source ./setup-python-3.0.sh ; then
+    exit $?
+fi
+
+cd ..
+source $PACKAGE/version.py
+echo $__version__
+
+for pyversion in $PYVERSIONS; do
+    echo --- $pyversion ---
+    if [[ ${pyversion:0:4} == "pypy" ]] ; then
+	echo "$pyversion - PyPy does not get special packaging"
+	continue
+    fi
+    if ! pyenv local $pyversion ; then
+	exit $?
+    fi
+    # pip bdist_egg create too-general wheels. So
+    # we narrow that by moving the generated wheel.
+
+    # Pick out first two number of version, e.g. 3.5.1 -> 35
+    first_two=$(echo $pyversion | cut -d'.' -f 1-2 | sed -e 's/\.//')
+    rm -fr build
+    python setup.py bdist_egg bdist_wheel
+    mv -v dist/${PACKAGE}-$__version__-{py2.py3,py$first_two}-none-any.whl
+    echo === $pyversion ===
+done
+
+python ./setup.py sdist
+tarball=dist/${PACKAGE}-${__version__}.tar.gz
+if [[ -f $tarball ]]; then
+    mv -v $tarball dist/${PACKAGE}_31-${__version__}.tar.gz
+fi
+finish

admin-tools/make-dist-3.3-3.5.sh

@@ -3,11 +3,11 @@ PACKAGE=uncompyle6
 
 # FIXME put some of the below in a common routine
 function finish {
-  cd $owd
+  cd $uncompyle6_33_make_owd
 }
 
 cd $(dirname ${BASH_SOURCE[0]})
-owd=$(pwd)
+uncompyle6_33_make_owd=$(pwd)
 trap finish EXIT
 
 if ! source ./pyenv-3.3-3.5-versions ; then
@@ -22,6 +22,11 @@ source $PACKAGE/version.py
 echo $__version__
 
 for pyversion in $PYVERSIONS; do
+    echo --- $pyversion ---
+    if [[ ${pyversion:0:4} == "pypy" ]] ; then
+	echo "$pyversion - PyPy does not get special packaging"
+	continue
+    fi
     if ! pyenv local $pyversion ; then
 	exit $?
     fi
@@ -33,6 +38,12 @@ for pyversion in $PYVERSIONS; do
     rm -fr build
     python setup.py bdist_egg bdist_wheel
     mv -v dist/${PACKAGE}-$__version__-{py2.py3,py$first_two}-none-any.whl
+    echo === $pyversion ===
 done
 
 python ./setup.py sdist
+tarball=dist/${PACKAGE}-${__version__}.tar.gz
+if [[ -f $tarball ]]; then
+    mv -v $tarball dist/${PACKAGE}_31-${__version__}.tar.gz
+fi
+finish

admin-tools/make-dist-newest.sh

@@ -3,11 +3,11 @@ PACKAGE=uncompyle6
 
 # FIXME put some of the below in a common routine
 function finish {
-  cd $owd
+  cd $make_uncompyle6_newest_owd
 }
 
 cd $(dirname ${BASH_SOURCE[0]})
-owd=$(pwd)
+make_uncompyle6_newest_owd=$(pwd)
 trap finish EXIT
 
 if ! source ./pyenv-newest-versions ; then
@@ -22,6 +22,11 @@ source $PACKAGE/version.py
 echo $__version__
 
 for pyversion in $PYVERSIONS; do
+    echo --- $pyversion ---
+    if [[ ${pyversion:0:4} == "pypy" ]] ; then
+	echo "$pyversion - PyPy does not get special packaging"
+	continue
+    fi
     if ! pyenv local $pyversion ; then
 	exit $?
     fi
@@ -36,3 +41,4 @@ for pyversion in $PYVERSIONS; do
 done
 
 python ./setup.py sdist
+finish

admin-tools/merge-for-2.4.sh

@@ -0,0 +1,7 @@
+#/bin/bash
+uncompyle6_merge_24_owd=$(pwd)
+cd $(dirname ${BASH_SOURCE[0]})
+if . ./setup-python-2.4.sh; then
+    git merge python-3.0-to-3.2
+fi
+cd $uncompyle6_merge_24_owd

admin-tools/merge-for-3.0.sh

@@ -0,0 +1,7 @@
+#/bin/bash
+uncompyle6_merge_30_owd=$(pwd)
+cd $(dirname ${BASH_SOURCE[0]})
+if . ./setup-python-3.0.sh; then
+    git merge python-3.3-to-3.5
+fi
+cd $uncompyle6_merge_30_owd

admin-tools/merge-for-3.3.sh

@@ -0,0 +1,7 @@
+#/bin/bash
+uncompyle6_merge_33_owd=$(pwd)
+cd $(dirname ${BASH_SOURCE[0]})
+if . ./setup-python-3.3.sh; then
+    git merge python-3.6-to-3.10
+fi
+cd $uncompyle6_merge_33_owd

admin-tools/merge-for-3.6.sh

@@ -0,0 +1,7 @@
+#/bin/bash
+uncompyle6_merge_36_owd=$(pwd)
+cd $(dirname ${BASH_SOURCE[0]})
+if . ./setup-python-3.6.sh; then
+    git merge master
+fi
+cd $uncompyle6_merge_36_owd

admin-tools/pyenv-newest-versions

@@ -5,4 +5,4 @@ if [[ $0 == ${BASH_SOURCE[0]} ]] ; then
     echo "This script should be *sourced* rather than run directly through bash"
     exit 1
 fi
-export PYVERSIONS='3.6.15 pypy3.6-7.3.1 3.7.16 pypy3.7-7.3.9 pypy3.8-7.3.10 pyston-2.3.5 3.8.16'
+export PYVERSIONS='3.6.15 pypy3.6-7.3.1 3.7.16 pypy3.7-7.3.9 pypy3.8-7.3.10 pyston-2.3.5 3.8.18'

admin-tools/setup-master.sh

@@ -1,31 +1,20 @@
 #!/bin/bash
-PYTHON_VERSION=3.7.14
-
-function checkout_version {
-    local repo=$1
-    version=${2:-master}
-    echo Checking out $version on $repo ...
-    (cd ../$repo && git checkout $version && pyenv local $PYTHON_VERSION) && \
-	git pull
-    return $?
-}
-
-# FIXME put some of the below in a common routine
-function finish {
-  cd $owd
-}
-
-export PATH=$HOME/.pyenv/bin/pyenv:$PATH
-owd=$(pwd)
+# Check out master branch and dependent development master branches
 bs=${BASH_SOURCE[0]}
 if [[ $0 == $bs ]] ; then
     echo "This script should be *sourced* rather than run directly through bash"
     exit 1
 fi
+
+PYTHON_VERSION=3.12
+
+uncompyle6_owd=$(pwd)
 mydir=$(dirname $bs)
 fulldir=$(readlink -f $mydir)
+cd $mydir
+. ./checkout_common.sh
 cd $fulldir/..
-(cd $fulldir/.. && checkout_version python-spark && checkout_version python-xdis &&
-      checkout_version python-uncompyle6)
-cd $owd
-rm -v */.python-version >/dev/null 2>&1 || true
+(cd $fulldir/.. && \
+     setup_version python-spark master && \
+     setup_version python-xdis master )
+checkout_finish master

admin-tools/setup-python-2.4.sh

@@ -1,24 +1,23 @@
 #!/bin/bash
-PYTHON_VERSION=2.4.6
+# Check out python-2.4-to-2.7 and dependent development branches.
 
-function checkout_version {
-    local repo=$1
-    version=${2:-python-2.4}
-    echo Checking out $version.4 on $repo ...
-    (cd ../$repo && git checkout $version && pyenv local $PYTHON_VERSION) && \
-	git pull
-    return $?
-}
-
-owd=$(pwd)
 bs=${BASH_SOURCE[0]}
 if [[ $0 == $bs ]] ; then
     echo "This script should be *sourced* rather than run directly through bash"
     exit 1
 fi
+
+PYTHON_VERSION=2.4
+
+uncompyle6_owd=$(pwd)
 mydir=$(dirname $bs)
 fulldir=$(readlink -f $mydir)
-(cd $fulldir/.. && checkout_version python-spark && checkout_version python-xdis python-2.4-to-2.7 &&
-      checkout_version python-uncompyle6)
-cd $owd
-rm -v */.python-version || true
+cd $mydir
+. ./checkout_common.sh
+
+(cd $fulldir/.. && \
+     setup_version python-spark python-2.4 && \
+     setup_version python-xdis python-2.4)
+
+
+checkout_finish python-2.4-to-2.7

admin-tools/setup-python-3.0.sh

@@ -1,35 +1,20 @@
 #!/bin/bash
-PYTHON_VERSION=3.0.1
-pyenv local $PYTHON_VERSION
-
-# FIXME put some of the below in a common routine
-function checkout_version {
-    local repo=$1
-    version=${2:-python-3.0-to-3.2}
-    echo Checking out $version on $repo ...
-    (cd ../$repo && git checkout $version && pyenv local $PYTHON_VERSION) && \
-	git pull
-    return $?
-}
-
-function finish {
-  cd $owd
-}
-
-export PATH=$HOME/.pyenv/bin/pyenv:$PATH
-owd=$(pwd)
+# Check out python-3.0-to-3.2 and dependent development branches.
 bs=${BASH_SOURCE[0]}
 if [[ $0 == $bs ]] ; then
     echo "This script should be *sourced* rather than run directly through bash"
     exit 1
 fi
 
+PYTHON_VERSION=3.0
+
+uncompyle6_owd=$(pwd)
 mydir=$(dirname $bs)
 fulldir=$(readlink -f $mydir)
-cd $fulldir/..
-(cd $fulldir/.. && checkout_version python-spark master && checkout_version python-xdis &&
-      checkout_version python-uncompyle6)
-cd $owd
-rm -v */.python-version || true
+cd $mydir
+. ./checkout_common.sh
+(cd $fulldir/.. && \
+     setup_version python-spark python-3.0 && \
+     setup_version python-xdis python-3.0)
 
-git checkout python-3.0-to-3.2  && git pull && pyenv local $PYTHON_VERSION
+checkout_finish python-3.0-to-3.2

admin-tools/setup-python-3.3.sh

@@ -1,35 +1,21 @@
 #!/bin/bash
-PYTHON_VERSION=3.3.7
-pyenv local $PYTHON_VERSION
-
-# FIXME put some of the below in a common routine
-function checkout_version {
-    local repo=$1
-    version=${2:-python-3.3-to-3.5}
-    echo Checking out $version on $repo ...
-    (cd ../$repo && git checkout $version && pyenv local $PYTHON_VERSION) && \
-	git pull
-    return $?
-}
-
-function finish {
-  cd $owd
-}
-
-export PATH=$HOME/.pyenv/bin/pyenv:$PATH
-owd=$(pwd)
+# Check out python-3.3-to-3.5 and dependent development branches.
 bs=${BASH_SOURCE[0]}
 if [[ $0 == $bs ]] ; then
     echo "This script should be *sourced* rather than run directly through bash"
     exit 1
 fi
 
-mydir=$(dirname $bs)
-fulldir=$(readlink -f $mydir)
-cd $fulldir/..
-(cd $fulldir/.. && checkout_version python-spark master && checkout_version python-xdis &&
-      checkout_version python-uncompyle6)
-cd $owd
-rm -v */.python-version || true
+PYTHON_VERSION=3.3
 
-git checkout python-3.3-to-3.5  && git pull && pyenv local $PYTHON_VERSION
+uncompyle6_owd=$(pwd)
+mydir=$(dirname $bs)
+cd $mydir
+fulldir=$(readlink -f $mydir)
+. ./checkout_common.sh
+cd $fulldir/..
+(cd $fulldir/.. && \
+     setup_version python-spark python-3.3 && \
+     setup_version python-xdis python-3.3 )
+
+checkout_finish python-3.3-to-3.5

admin-tools/setup-python-3.6.sh

@@ -0,0 +1,21 @@
+#!/bin/bash
+# Check out python-3.6-to-3.10 and dependent development branches.
+bs=${BASH_SOURCE[0]}
+if [[ $0 == $bs ]] ; then
+    echo "This script should be *sourced* rather than run directly through bash"
+    exit 1
+fi
+
+PYTHON_VERSION=3.6
+
+uncompyle6_owd=$(pwd)
+mydir=$(dirname $bs)
+cd $mydir
+fulldir=$(readlink -f $mydir)
+. ./checkout_common.sh
+cd $fulldir/..
+(cd $fulldir/.. && \
+     setup_version python-spark python-3.6 && \
+     setup_version python-xdis python-3.6 )
+
+checkout_finish python-3.6-to-3.10

pyproject.toml

@@ -0,0 +1,65 @@
+[build-system]
+requires = [
+    "setuptools",
+    # "setuptools>=59.6.0", # for 3.6
+]
+
+build-backend = "setuptools.build_meta"
+
+[project]
+authors = [
+    {name = "Rocky Bernstein",	email = "rb@dustyfeet.com"},
+]
+
+name = "uncompyle6"
+description = "Python cross-version byte-code library and disassembler"
+dependencies = [
+    "click",
+    "spark-parser >= 1.8.9, < 1.9.2",
+    "xdis >= 6.1.0, < 6.2.0",
+]
+readme = "README.rst"
+license = {text = "GPL"}
+keywords = ["Python bytecode", "bytecode", "disassembler"]
+classifiers = [
+    "Development Status :: 5 - Production/Stable",
+    "Intended Audience :: Developers",
+    "License :: OSI Approved :: MIT License",
+    "Programming Language :: Python",
+    "Topic :: Software Development :: Libraries :: Python Modules",
+    "Programming Language :: Python :: 2.4",
+    "Programming Language :: Python :: 2.5",
+    "Programming Language :: Python :: 2.6",
+    "Programming Language :: Python :: 2.7",
+    "Programming Language :: Python :: 3.0",
+    "Programming Language :: Python :: 3.1",
+    "Programming Language :: Python :: 3.2",
+    "Programming Language :: Python :: 3.3",
+    "Programming Language :: Python :: 3.4",
+    "Programming Language :: Python :: 3.5",
+    "Programming Language :: Python :: 3.6",
+    "Programming Language :: Python :: 3.7",
+    "Programming Language :: Python :: 3.8",
+    "Programming Language :: Python :: 3.9",
+    "Programming Language :: Python :: 3.10",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
+]
+dynamic = ["version"]
+
+[project.urls]
+Homepage = "https://github.com/rocky/python-uncompyle6"
+Downloads = "https://github.com/rocky/python-uncompyle6/releases"
+
+[project.optional-dependencies]
+dev = [
+    "pre-commit",
+    "pytest",
+]
+
+[project.scripts]
+uncompyle6 = "uncompyle6.bin.uncompile:main_bin"
+uncompyle6-tokenize = "uncompyle6.bin.pydisassemble:main"
+
+[tool.setuptools.dynamic]
+version = {attr = "uncompyle6.version.__version__"}

pytest/test_fjt.py

@@ -27,7 +27,7 @@ def test_if_in_for():
         fjt = scan.find_jump_targets(False)
 
         ## FIXME: the data below is wrong.
-        ## we get different results currenty as well.
+        ## we get different results currently as well.
         ## We need to probably fix both the code
         ## and the test below
         # assert {15: [3], 69: [66], 63: [18]} == fjt

pytest/validate.py

@@ -67,7 +67,7 @@ def are_instructions_equal(i1, i2):
     Determine if two instructions are approximately equal,
     ignoring certain fields which we allow to differ, namely:
 
-    * code objects are ignore (should probaby be checked) due to address
+    * code objects are ignore (should probably be checked) due to address
     * line numbers
 
     :param i1: left instruction to compare

requirements.txt

@@ -6,4 +6,4 @@ pytest
 Click~=7.0
 xdis>=6.0.4
 configobj~=5.0.6
-setuptools~=65.3.0
+setuptools

setup-pretoml.py

@@ -0,0 +1,71 @@
+#!/usr/bin/env python
+import sys
+
+import setuptools
+
+"""Setup script for the 'uncompyle6' distribution."""
+
+SYS_VERSION = sys.version_info[0:2]
+if SYS_VERSION < (3, 6):
+    mess = "Python Release 3.6 .. 3.12 are supported in this code branch."
+    if (2, 4) <= SYS_VERSION <= (2, 7):
+        mess += (
+            "\nFor your Python, version %s, use the python-2.4 code/branch."
+            % sys.version[0:3]
+        )
+    if SYS_VERSION >= (3, 6):
+        mess += (
+            "\nFor your Python, version %s, use the master code/branch."
+            % sys.version[0:3]
+        )
+    if (3, 0) >= SYS_VERSION < (3, 3):
+        mess += (
+            "\nFor your Python, version %s, use the python-3.0-to-3.2 code/branch."
+            % sys.version[0:3]
+        )
+    if (3, 3) >= SYS_VERSION < (3, 6):
+        mess += (
+            "\nFor your Python, version %s, use the python-3.3-to-3.5 code/branch."
+            % sys.version[0:3]
+        )
+    elif SYS_VERSION < (2, 4):
+        mess += (
+            "\nThis package is not supported for Python version %s." % sys.version[0:3]
+        )
+    print(mess)
+    raise Exception(mess)
+
+from __pkginfo__ import (
+    __version__,
+    author,
+    author_email,
+    classifiers,
+    entry_points,
+    install_requires,
+    license,
+    long_description,
+    modname,
+    py_modules,
+    short_desc,
+    web,
+    zip_safe,
+)
+
+setuptools.setup(
+    author=author,
+    author_email=author_email,
+    classifiers=classifiers,
+    description=short_desc,
+    entry_points=entry_points,
+    install_requires=install_requires,
+    license=license,
+    long_description=long_description,
+    long_description_content_type="text/x-rst",
+    name=modname,
+    packages=setuptools.find_packages(),
+    py_modules=py_modules,
+    test_suite="nose.collector",
+    url=web,
+    version=__version__,
+    zip_safe=zip_safe,
+)

setup.cfg

@@ -12,10 +12,11 @@ doc_files = README.rst
 #		examples/
 
 [bdist_wheel]
-universal=1
+universal = no
 
 [metadata]
 description_file = README.rst
+licences_files = COPYING
 
 [flake8]
 # max-line-length setting: NO we do not want everyone writing 120-character lines!

setup.py

@@ -1,61 +1,6 @@
 #!/usr/bin/env python
-import setuptools
-import sys
-
 """Setup script for the 'uncompyle6' distribution."""
 
-SYS_VERSION = sys.version_info[0:2]
-if not ((2, 4) <= SYS_VERSION < (3, 12)):
-    mess = "Python Release 2.6 .. 3.11 are supported in this code branch."
-    if (2, 4) <= SYS_VERSION <= (2, 7):
-        mess += (
-            "\nFor your Python, version %s, use the python-2.4 code/branch."
-            % sys.version[0:3]
-        )
-    if (3, 3) <= SYS_VERSION < (3, 6):
-        mess += (
-            "\nFor your Python, version %s, use the python-3.3-to-3.5 code/branch."
-            % sys.version[0:3]
-        )
-    elif SYS_VERSION < (2, 4):
-        mess += (
-            "\nThis package is not supported for Python version %s." % sys.version[0:3]
-        )
-    print(mess)
-    raise Exception(mess)
+from setuptools import setup
 
-from __pkginfo__ import (
-    author,
-    author_email,
-    install_requires,
-    license,
-    long_description,
-    classifiers,
-    entry_points,
-    modname,
-    py_modules,
-    short_desc,
-    __version__,
-    web,
-    zip_safe,
-)
-
-setuptools.setup(
-    author=author,
-    author_email=author_email,
-    classifiers=classifiers,
-    description=short_desc,
-    entry_points=entry_points,
-    install_requires=install_requires,
-    license=license,
-    long_description=long_description,
-    long_description_content_type="text/x-rst",
-    name=modname,
-    packages=setuptools.find_packages(),
-    py_modules=py_modules,
-    test_suite="nose.collector",
-    url=web,
-    tests_require=["nose>=1.0"],
-    version=__version__,
-    zip_safe=zip_safe,
-)
+setup(packages=["uncompyle6"])

test/Makefile

@@ -115,7 +115,7 @@ check-bytecode-2:
 # FIXME: Until we shaked out problems with xdis...
 check-bytecode-3:
 	$(PYTHON) test_pythonlib.py \
-	--bytecode-3.4 --bytecode-3.5 --bytecode-3.6 \
+	--bytecode-3.3 --bytecode-3.4 --bytecode-3.5 --bytecode-3.6 \
         --bytecode-3.7  --bytecode-3.8
 
 #: Check deparsing on selected bytecode 3.x

test/decompyle/test_prettyprint.py

@@ -1,6 +1,6 @@
 """
 test_prettyprint.py --	source test pattern for tesing the prettyprint
-			funcionality of decompyle
+			functionality of decompyle
 
 This source is part of the decompyle test suite.
 

test/ok_lib2.7/bsddb/dbshelve.py

@@ -29,6 +29,7 @@ storage.
 #------------------------------------------------------------------------
 
 import sys
+
 absolute_import = (sys.version_info[0] >= 3)
 if absolute_import :
     # Because this syntaxis is not valid before Python 2.5
@@ -229,7 +230,7 @@ class DBShelf(MutableMapping):
 
     def associate(self, secondaryDB, callback, flags=0):
         def _shelf_callback(priKey, priData, realCallback=callback):
-            # Safe in Python 2.x because expresion short circuit
+            # Safe in Python 2.x because expression short circuit
             if sys.version_info[0] < 3 or isinstance(priData, bytes) :
                 data = cPickle.loads(priData)
             else :
@@ -366,7 +367,7 @@ class DBShelfCursor:
             return None
         else:
             key, data = rec
-            # Safe in Python 2.x because expresion short circuit
+            # Safe in Python 2.x because expression short circuit
             if sys.version_info[0] < 3 or isinstance(data, bytes) :
                 return key, cPickle.loads(data)
             else :

test/simple_source/bug25/06_if_and_bugs.py

@@ -0,0 +1,18 @@
+# 2.5 Bug is from nose/plugins/cover.py
+def wantFile(self, file, package=None):
+    if self.coverInclusive:
+        if file.endswith(".py"):
+            if package and self.coverPackages:
+                for want in self.coverPackages:
+                    if package.startswith(want):
+                        return True
+            else:
+                return True
+    return None
+
+
+# 2.5 bug is from nose/plugins/doctests.py
+def wantFile2(self, file):
+    if self and (self.conf or [exc.search(file) for exc in self.conf]):
+        return True
+    return None

test/simple_source/bug26/.gitignore

@@ -0,0 +1 @@
+/.python-version

test/simple_source/bug26/03_weird26.py

@@ -6,7 +6,7 @@
 [x for x in range(10) if x % 2 if x % 3]
 list(x for x in range(10) if x % 2 if x % 3)
 
-# expresion which evaluates True unconditionally,
+# expression which evaluates True unconditionally,
 # but leave dead code or junk around that we have to match on.
 # Tests "if_exp_true" rule
 5 if 1 else 2

test/simple_source/bug26/07_try_except.py

@@ -0,0 +1,34 @@
+# Bug portion of Issue #405 https://github.com/rocky/python-uncompyle6/issues/405
+# Bug was detecting if/else as the last item in a "try: .. except" block.
+class Saveframe(object):
+    """A saveframe. Use the classmethod from_scratch to create one."""
+
+    frame_list = {}
+
+    def frame_dict(self):
+        return
+
+    # Next line is 1477
+    def __setitem__(self, key, item):
+        # Next line is 1481
+        if isinstance(item, Saveframe):
+            try:
+                self.frame_list[key] = item
+            except TypeError:
+                if key in (self.frame_dict()):
+                    dict((frame.name, frame) for frame in self.frame_list)
+                    for pos, frame in enumerate(self.frame_list):
+                        if frame.name == key:
+                            self.frame_list[pos] = item
+                else:
+                    raise KeyError(
+                        "Saveframe with name '%s' does not exist and "
+                        "therefore cannot be written to. Use the add_saveframe method to add new saveframes."
+                        % key
+                    )
+        # Next line is 1498
+        raise ValueError("You can only assign an entry to a saveframe splice.")
+
+
+x = Saveframe()
+x.__setitem__("foo", 5)

test/simple_source/bug27+/01_argument_quoting.py

@@ -0,0 +1,7 @@
+# Bug was erroneously putting quotes around Exception on decompilatoin
+# RUNNABLE!
+
+"""This program is self-checking!"""
+z = ["y", Exception]
+assert z[0] == "y"
+assert isinstance(z[1], Exception)

test/simple_source/bug27+/01_module_doc.py

@@ -1,8 +1,8 @@
 # From 2.7.17 test_bdb.py
-# The problem was detecting a docstring at the begining of the module
+# The problem was detecting a docstring at the beginning of the module
 # It must be detected and change'd or else the "from __future__" below
 # is invalid.
-# Note that this has to be compiled with optimation < 2 or else optimization
+# Note that this has to be compiled with optimization < 2 or else optimization
 # will remove the docstring
 """Rational, infinite-precision, real numbers."""
 

test/simple_source/bug27+/03_comprehension_in_lambda.py

@@ -0,0 +1,11 @@
+# RUNNABLE!
+# From issue 469
+
+"""This program is self-checking!"""
+
+my_dict = (lambda variable0: {variable1: 123 for variable1 in variable0})([1, 2, 3])
+
+assert my_dict[1] == 123
+
+my_set = (lambda variable0: {variable1 for variable1 in variable0})([1, 2, 3])
+assert 2 in my_set

test/simple_source/bug27+/04_try_tryelse.py

@@ -1,5 +1,5 @@
 # From 2.7 test_normalize.py
-# Bug has to to with finding the end of the tryelse block. I think thrown
+# Bug has to do with finding the end of the tryelse block. I think thrown
 # off by the "continue". In instructions the COME_FROM for END_FINALLY
 # was at the wrong offset because some sort of "rtarget" was adjust.
 

test/simple_source/bug30/01_ops.py

@@ -1,7 +1,7 @@
 # Statements to beef up grammar coverage rules
 # Force "inplace" ops
 # Note this is like simple_source/bug22/01_ops.py
-# But we don't ahve the UNARY_CONVERT which dropped
+# But we don't have the UNARY_CONVERT which dropped
 # out around 2.7
 y = +10  # UNARY_POSITIVE
 y /= 1  # INPLACE_DIVIDE

test/simple_source/bug33/01_triple_compare.py

@@ -1,7 +1,7 @@
 # In Python 3.3+ this uses grammar rule
-# compare_chained2 ::= expr COMPARE_OP RETURN_VALUE
+# compare_chained_right ::= expr COMPARE_OP RETURN_VALUE
 # In Python 3.6 uses this uses grammar rule
-# compare_chained2 ::= expr COMPARE_OP come_froms JUMP_FORWARD
+# compare_chained_right ::= expr COMPARE_OP come_froms JUMP_FORWARD
 
 # Seen in Python 3.3 ipaddress.py
 

test/simple_source/bug33/04_lambda_star_default.py

@@ -1,18 +1,20 @@
 # From 3.x test_audiop.py
 
 # Bug is handling default value after * argument in a lambda.
-# That's a mouthful of desciption; I am not sure if the really
+# That's a mouthful of description; I am not sure if the really
 # hacky fix to the code is even correct.
 
 #
 # FIXME: try and test with more than one default argument.
 
+
 # RUNNABLE
 def pack(width, data):
     return (width, data)
 
+
 packs = {w: (lambda *data, width=w: pack(width, data)) for w in (1, 2, 4)}
 
-assert packs[1]('a') == (1, ('a',))
-assert packs[2]('b') == (2, ('b',))
-assert packs[4]('c') == (4, ('c',))
+assert packs[1]("a") == (1, ("a",))
+assert packs[2]("b") == (2, ("b",))
+assert packs[4]("c") == (4, ("c",))

test/simple_source/bug33/08_if_else.py

@@ -1,16 +1,19 @@
 # From python 3.3.7 trace
 # Bug was not having not having semantic rule for conditional not
 
+
 # RUNNABLE!
 def init(modules=None):
     mods = set() if not modules else set(modules)
     return mods
 
+
 assert init() == set()
 assert init([1, 2, 3]) == set([1, 2, 3])
 
+
 # From 3.6 sre_parse
-# Bug was in handling multple COME_FROMS from nested if's
+# Bug was in handling multiple COME_FROMS from nested if's
 def _escape(a, b, c, d, e):
     if a:
         if b:
@@ -24,6 +27,7 @@ def _escape(a, b, c, d, e):
             return
         raise
 
+
 assert _escape(False, True, True, True, True) is None
 assert _escape(True, True, True, False, True) is None
 assert _escape(True, True, False, False, True) is None

test/simple_source/bug34/02_make_closure.py

@@ -0,0 +1,18 @@
+# Related to #426
+
+# This file is RUNNABLE!
+"""This program is self-checking!"""
+
+a = 5
+class MakeClosureTest():
+    # This function uses MAKE_CLOSURE with annotation args
+    def __init__(self, dev: str, b: bool):
+        super().__init__()
+        self.dev = dev
+        self.b = b
+        self.a = a
+
+x = MakeClosureTest("dev", True)
+assert x.dev == "dev"
+assert x.b == True
+assert x.a == 5

test/simple_source/bug34/03_ifelse_in_lambda.py

@@ -0,0 +1,4 @@
+# Next line is 1164
+def foo():
+    name = "bar"
+    lambda x: compile(x, "<register %s's commit>" % name, "exec") if x else None

test/simple_source/bug35/02_for_else_bug.py

@@ -0,0 +1,10 @@
+# Adapted 3.5 from _bootstrap_external.py
+
+
+def spec_from_file_location(loader, location):
+    if loader:
+        for _ in __file__:
+            if location:
+                break
+        else:
+            return None

test/simple_source/bug35/06_while_return.py

@@ -1,8 +1,9 @@
 # From Python 3.4 asynchat.py
-# Tests presence or absense of
+# Tests presence or absence of
 # SETUP_LOOP testexpr return_stmts POP_BLOCK COME_FROM_LOOP
 # Note: that there is no JUMP_BACK because of the return_stmts.
 
+
 def initiate_send(a, b, c, num_sent):
     while a and b:
         try:
@@ -24,6 +25,7 @@ def initiate_send2(a, b):
 
         return 2
 
+
 assert initiate_send(1, 1, 2, False) == 1
 assert initiate_send(1, 2, 3, False) == 3
 assert initiate_send(1, 2, 3, True) == 2

test/simple_source/bug36/02_kwargs.py

@@ -5,7 +5,7 @@ def bug(self, j, a, b):
     self.parse_comment(a, b, report=3)
 
 # From 3.6 fnmatch.py
-# Bug was precidence parenthesis around decorator
+# Bug was precedence parenthesis around decorator
 
 import functools
 @functools.lru_cache(maxsize=256, typed=True)

test/simple_source/bug36/03_fn_defaults.py

@@ -1,13 +1,20 @@
-# Python 3.6 changes, yet again, the way deafult pairs are handled
+# Python 3.6 changes, yet again, the way default pairs are handled
 def foo1(bar, baz=1):
     return 1
+
+
 def foo2(bar, baz, qux=1):
     return 2
+
+
 def foo3(bar, baz=1, qux=2):
     return 3
+
+
 def foo4(bar, baz, qux=1, quux=2):
     return 4
 
+
 # From 3.6 compileall.
 # Bug was in omitting default which when used in an "if"
 # are treated as False would be

test/simple_source/bug36/04_class_kwargs.py

@@ -1,17 +1,23 @@
 # From 3.6 test_abc.py
-# Bug was Reciever() class definition
+# Bug was Receiver() class definition
 import abc
 import unittest
+
+
 class TestABCWithInitSubclass(unittest.TestCase):
     def test_works_with_init_subclass(self):
         class ReceivesClassKwargs:
             def __init_subclass__(cls, **kwargs):
                 super().__init_subclass__()
+
         class Receiver(ReceivesClassKwargs, abc.ABC, x=1, y=2, z=3):
             pass
 
+
 def test_abstractmethod_integration(self):
     for abstractthing in [abc.abstractmethod]:
+
         class C(metaclass=abc.ABCMeta):
             @abstractthing
-            def foo(self): pass  # abstract
+            def foo(self):
+                pass  # abstract

test/simple_source/bug36/05_if_and_comp.py

@@ -1,12 +1,12 @@
 # From 3.6 base64.py
-# Bug was handling "and" condition in the presense of POP_JUMP_IF_FALSE
+# Bug was handling "and" condition in the presence of POP_JUMP_IF_FALSE
 # locations
 def _85encode(foldnuls, words):
-    return ['z' if foldnuls and word
-                else  'y'
-                for word in words]
+    return ["z" if foldnuls and word else "y" for word in words]
+
 
 # From Python 3.6 enum.py
 
+
 def __new__(metacls, cls, bases, classdict):
     {k: classdict[k] for k in classdict._member_names}

test/simple_source/bug36/09_long_whilestmt.py

@@ -0,0 +1,74 @@
+# From https://github.com/rocky/python-uncompyle6/issues/420
+# Related to EXTENDED_ARG in whilestmt
+ERRPR_CODE_DEFINE = {}  # Remove this and things works
+
+try:
+    print()
+except Exception:
+    var1 = 0
+    var2 = 1
+    if var1 or var2:
+        times = 1
+        while times != False and self.scanner.is_open():
+            try:
+                try:
+                    print()
+                except Exception:
+                    print()
+
+                out = 0
+                count = 1
+                if out == 1:
+                    break
+                elif out == 2:
+                    count += 1
+                    if times == 3:
+                        self.func.emit({})
+                        break
+                    else:
+                        continue
+                if out == 3 or out == b"":
+                    if self.times == 3:
+                        break
+                    count += 1
+                    if count == 3:
+                        count = 0
+                        if out == 4:
+                            self.func.emit(ERRPR_CODE_DEFINE.ReceiedError())
+                        else:
+                            print()
+                        break
+                    continue
+                else:
+                    count = 0
+            except Exception:
+                print("upper exception")
+    else:
+        try:
+            print("jump forward")
+            while True:
+                out = self.func.read(count)
+                if out == b"":
+                    self.func.emit(ERRPR_CODE_DEFINE.ReceiedError())
+                    break
+                    continue
+                imagedata = out[0]
+                if imagedata == b"\x05":
+                    self.func.emit(INFORMATION.UnsupportedImage())
+                    break
+                    continue
+                if imagedata == b"\x15":
+                    self.func.emit(INFORMATION.NoneImage())
+                    break
+                    continue
+                if out[1] == False:
+                    start_index = imagedata.find(b"BM6")
+                    self.func.emit(imagedata[start_index:], False)
+                    continue
+                (imagedata, all_code) = imagedata
+                self.func.emit({})
+                self.func.emit({})
+                self.func.emit({})  # remove {} and this works
+                break
+        except Exception:
+            pass

test/simple_source/bug36/10_fstring.py

@@ -14,6 +14,7 @@ assert (
 assert "def0" == f"{abc}0"
 assert "defdef" == f"{abc}{abc!s}"
 
+
 # From 3.8 test/test_string.py
 # We had the precedence of yield vs. lambda incorrect.
 def fn(x):
@@ -97,9 +98,10 @@ else:
 (x, y, width) = ("foo", 2, 10)
 assert f"x={x*y:{width}}" == "x=foofoo    "
 
+
 # Why the fact that the distinction of docstring versus stmt is a
 # string expression is important academic, but we will decompile an
-# equivalent thing. For compatiblity with older Python we'll use "%"
+# equivalent thing. For compatibility with older Python we'll use "%"
 # instead of a format string
 def f():
     f"""Not a docstring"""  # noqa

test/simple_source/bug36/10_long_pop_jump.py

@@ -1,22 +1,23 @@
 # From 3.6 _markupbase.py
 
-# Bug is that the routine is long enough that POP_JUMP_IF_FALSE instruciton has an
-# EXTENDED_ARG intruction before it and we weren't picking out the jump offset properly
+# Bug is that the routine is long enough that POP_JUMP_IF_FALSE instruction has an
+# EXTENDED_ARG instruction before it and we weren't picking out the jump offset properly
+
 
 def parse_declaration(self, i):
     if rawdata[j:j] in ("-", ""):
         return -1
     n = len(rawdata)
-    if rawdata[j:j+2] == '-':
+    if rawdata[j : j + 2] == "-":
         return self.parse_comment(i)
-    elif rawdata[j] == '[':
+    elif rawdata[j] == "[":
         return self.parse_marked_section(i)
     else:
         decltype, j = self._scan_name(j, i)
     if j < 0:
         return j
     if decltype == "d":
-        self._decl_otherchars = ''
+        self._decl_otherchars = ""
     while j < n:
         c = rawdata[j]
         if c == ">":
@@ -43,8 +44,7 @@ def parse_declaration(self, i):
             else:
                 self.error("unexpected '[' char in declaration")
         else:
-            self.error(
-                "unexpected %r char in declaration" % rawdata[j])
+            self.error("unexpected %r char in declaration" % rawdata[j])
         if j < 0:
             return j
     return -1

test/simple_source/bug38/03_while_bug.py

@@ -0,0 +1,9 @@
+# See https://github.com/rocky/python-uncompyle6/issues/498
+# Bug was in not allowing _stmts in whilestmt38
+import time
+
+r = 0
+while r == 1:
+    print(time.time())
+    if r == 1:
+        r = 0

test/simple_source/calls/01_positional.py

@@ -1,5 +1,5 @@
 # Tests custom added grammar rule:
 #   expr ::= expr {expr}^n CALL_FUNCTION_n
-# which in the specifc case below is:
+# which in the specific case below is:
 #   expr ::= expr expr expr CALL_FUNCTION_2
 max(1, 2)

test/simple_source/expression/05_long_literals.py

@@ -725,3 +725,13 @@ values = {
 }
 
 assert sorted(values.values())[1:] == list(range(2, 34))
+
+def assert_equal(x, y):
+    assert x == y
+
+# Check that we can distinguish names from strings in literal collections, e.g. lists.
+# The list has to have more than 4 items to get accumulated in a collection
+a = ["y", 'Exception', "x", Exception, "z"]
+
+assert_equal(a[1], "Exception")
+assert_equal(a[3], Exception)

test/simple_source/looping/04_while1_while1.py

@@ -27,7 +27,7 @@ while 1:
     else:
         raise RuntimeError
 
-# Degenerate case. Note: we can't run becase this causes an infinite loop.
+# Degenerate case. Note: we can't run because this causes an infinite loop.
 # Suggested in issue #172
 while 1:
     pass

test/simple_source/operation_logic/05_control_flow_bugs.py

@@ -1,7 +1,8 @@
 # From 3.6.10 test_binascii.py
-# Bug was getting "while c and noise" parsed correclty
+# Bug was getting "while c and noise" parsed correctly
 # and not put into the "ifelsesmt"
 
+
 # RUNNABLE!
 def addnoise(c, noise):
     while c and noise:
@@ -12,6 +13,7 @@ def addnoise(c, noise):
         noise = False
     return c
 
+
 assert addnoise(0, True) == 0
 assert addnoise(1, False) == 1
 assert addnoise(2, True) == 2
@@ -19,9 +21,10 @@ assert addnoise(3, True) == 3
 assert addnoise(4, True) == 3
 assert addnoise(5, False) == 5
 
+
 # From 3.6.10 test_dbm_dumb.py
 # Bug was getting attaching "else" to the right "if" in the
-# presense of a loop.
+# presence of a loop.
 def test_random(a, r):
     x = 0
     for dummy in r:
@@ -32,11 +35,13 @@ def test_random(a, r):
             x += 1
     return x
 
+
 assert test_random(True, [1]) == 2
 assert test_random(True, [1, 1]) == 4
 assert test_random(False, [1]) == 0
 assert test_random(False, [1, 1]) == 0
 
+
 # From 2.7.17 test_frozen.py
 # Bug was getting making sure we have "try" not
 # "try"/"else"
@@ -53,11 +58,13 @@ def test_frozen(a, b):
 
     return x
 
+
 assert test_frozen(1, 1) == 4.0
 assert test_frozen(0, 1) == 5.0
 assert test_frozen(0.5, 0) == 6.0
 assert test_frozen(0, 0.5) == 8.0
 
+
 # From 3.6.10 test_binop.py
 # Bug was getting "other += 3" outside of "if"/"else.
 def __floordiv__(a, b):
@@ -70,6 +77,7 @@ def __floordiv__(a, b):
     other += 3
     return other
 
+
 assert __floordiv__(True, True) == 4
 assert __floordiv__(True, False) == 4
 assert __floordiv__(False, True) == 3

test/simple_source/operation_logic/10_mixed_boolean.py

@@ -1,19 +1,19 @@
 # Self-checking test.
-# Mixed boolean expresions
+# Mixed boolean expressions
 
 b = True
-assert b, 'b = True'
+assert b, "b = True"
 c = False
-assert not c, 'c = False'
+assert not c, "c = False"
 d = True
 a = b and c or d
-assert a, 'b and c or d'
+assert a, "b and c or d"
 a = (b or c) and d
-assert a, '(b or c) and d'
+assert a, "(b or c) and d"
 a = b or c or d
-assert  a, 'b or c or d'
+assert a, "b or c or d"
 a = b and c and d
-assert not a, 'b and c and d'
+assert not a, "b and c and d"
 a = b or c and d
 assert a
 a = b and (c or d)

test/simple_source/stmts/03_if_elif.py

@@ -1,5 +1,5 @@
 # 2.6.9 symbols.py
-# Bug in 2.6 is having multple COME_FROMs due to the
+# Bug in 2.6 is having multiple COME_FROMs due to the
 # "and" in the "if" clause
 
 # RUNNABLE
@@ -10,7 +10,7 @@ if __name__:
         assert False
 
 # 2.6.9 transformer.py
-# Bug in 2.6 is multple COME_FROMs as a result
+# Bug in 2.6 is multiple COME_FROMs as a result
 # of the "or" in the "assert"
 
 # In PyPy the assert is handled via PyPy's unique JUMP_IF_NOT_DEBUG
@@ -24,6 +24,7 @@ elif __file__:
 else:
     pass
 
+
 # From 3.3.7 test_binop.py
 # Bug was in ifelsestmt(c) ensuring b+=5 is not in "else"
 # Also note: ifelsetmtc should not have been used since this
@@ -36,6 +37,7 @@ def __floordiv__(a, b):
     b += 5
     return b
 
+
 assert __floordiv__(1, 1) == 7
 assert __floordiv__(1, 0) == 6
 assert __floordiv__(0, 3) == 8

test/simple_source/stmts/08_test_contextmanager.py

@@ -0,0 +1,21 @@
+"""
+This program is self checking!
+"""
+
+
+class TestContextManager:
+    def __enter__(self):
+        return 1, 2
+
+    def __exit__(self, exc_type, exc_value, exc_tb):
+        return self, exc_type, exc_value, exc_tb
+
+
+with open(__file__) as a:
+    assert a
+
+with open(__file__) as a, open(__file__) as b:
+    assert a.read() == b.read()
+
+with TestContextManager() as a, b:
+    assert (a, b) == (1, 2)