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.
This builds on top of my previous PR.
The idea here is start organizing the API to make it easier to keep track of what API calls have a Python call, and which don't. Currently the change is minimal to demonstrate the idea.
Basically for each group of related functionalities the idea is to make a single "mixin" class that contains those methods. Then the
API
class is a nearly empty class that just inherits from all of the "mixin" classes, thus providing a backwards compatibility.However, now we don't need comments to delineate grouping of functionality as it is implicit in the code.
As an example of what I'm trying to do, I've had a lot of success with this pattern in my CocoDataset class. I think this pattern will have value here as well.
The current group of mixins uses the same structure implied by the comments. We have:
I also added a doctest to API, which won't run, but illustrates how to create an instance of it. If the testing tools have something that can spin up a dummy server, then we could make this test actually run with xdoctest.