[WIP] Audit return types #724
Closed
Conversation
This file contains 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
|
I am going to close this now as I do not intend for it to ever be merged, and #726 exists as a first step |
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.
In this PR I try to make a bunch of changes at once to input / return types across chaco and see what happens.
Note the changes in this PR could fix (potentially) #272, #289, #550, and more. Eventually I will verify these things and try to write regression tests.
I currently am treating this PR as an experiment. I imagine the changes here will likely be pulled out into various, more incremental, small PRs that slowly make a migration. If this PR ever is to be merged in its entirety, it will require substantial clean up and tests.
A struggle with making these changes is lack of coverage (we could be breaking other things internally even if test suite passes), and Hyrum's law. Almost certainly downstream users are depending on these return types in one way or the other. The issue description on #550 very nicely describes how these differences across the codebase force other code to assume one way or the other... Users likely have had to make that assumption that holds true for their particular use case.