Refactoring of Generators #118
Draft
+754
−517
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Code formatting issues from the linter. Pruned imports per linter Provide more information in error-handler. Replace error print statements with logging messages at error level. Tweak error handling.
Removed mutable default values. Removed equality comparisons against None.
Looking at the README in the PyCharm IDE, discovered that it incorrectly referenced `print_prog_score`. This is not a function, but a method on `Settings`.
Change to explicitly make the default logging level be WARNING.
|
I am going to rewrite the history here and then force push it -- the history is a little ugly at present. |
Add `resource_string.py` that provides a compatibility layer between versions of Python that do and don't have the `pkg_resources` library, removed in version 3.12.
Create two new methods, `build_encoding` and `init_solver` that encapsulate the set up of the solver. Did this for my own purposes, but it simplifies the code, as well, and could be used later to reduce code duplication.
To avoid circularities introduced by type checking, move some type declarations up into a file, type_defs.py, that can be loaded first.
This method definition appeared only in generate.py, but it was also invoked in gen3.py, where it was not defined. Added it to the abstract parent class of all the generators.
We are getting some errors in returns from SWI prolog. Catch them and treat them as query failures.
There were some abstract methods declared that are not present in Generator 2 (gen2.py). Removed them from the ABC definition.
Added property type hints to the abstract `Generator` class. Stumbled on these when checking some calling code with mypy. This caused me to fix the `init_solver` method in gen2.py. Previously, this would only set the solver property if `settings.single_solve` was true. But gen2 is only used if `single_solve` is true, so I removed that condition. If that condition was false, then `init_solver` would fail in odd ways because it would set properties on the `solver` but `solver` would be unbound.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Draft of refactoring of Popper's generators. Adds an abstract class that is the parent of the three alternate generators.
loop.pynow imports all three of them, and addsPopper.select_generator()method to encapsulate the choice process.This is very unlikely to be ready for adoption, but it seems not to break anything, based on test runs, and I hoped it would be of interest.
I did this to make it possible to tailor generators, but it also has the advantage of making it possible for type checkers and other linters to check the generator code and how it's used in the rest of Popper.
I added a couple of new type definitions into abs_generate.py, which caused a little fuss because these use type definitions from popper.util. Although this is circular, it's not a problem when type-checking (see the wrapping of imports at the head of
abs_generate.py). But it's untidy; it would probably be more elegant to have a file of miscellaneous type definitions w/o code that could be loaded early in load order.The diff is ugly, I'm afraid, because this was built on top of the linter improvements in #115. If that can be merged, then the diffs here would clean up.