Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed updates for PR 496 #11

Closed

Conversation

mkavulich
Copy link

Change 1: Convert "Case_Data" object to a simple dictionary. This will be much simpler than maintaining a custom object (which seems like overkill in this case), eliminates a ton of redundant code, and avoids the pitfall of accessing internal variables. In making this conversion I discovered an error in the code (which is almost inevitable with so much duplication): w_d was assigned the value of w_0. This may have implications for already-converted data.

Change 2: Make "debug" logging a command-line argument rather than requiring manual editing of code

Change 3: Fix calls to logging.critical that had a missing required argument.

Change 4: Remove old commented prints/exceptions

…shorter and will make list maintenance less of a hassle if changes are needed
…nates a ton of redundant code, and avoids the pitfall of accessing internal class variables
 - Fix some bad references to "missing_value" outside dictionary
 - Remove some old commented prints
 - Fix calls to logging.critical() with no argument
@grantfirl
Copy link
Owner

@mkavulich I had designs on expanding the case object in the future. I agree that it is overkill for this application right now. Given the large number of changes and the fact that all of the cases were already converted and tested, I'd rather not merge these changes before the release. We can revisit after the release. The debug option, logging.critical fixes, and w_0 bug are fixed via your "essential" PR or separate commit.

@mkavulich
Copy link
Author

Sounds good to me. If we're keeping the Case_Data object, the only additional change I'd make is to change the names to omit leading underscores, since this is the naming convention for internal-use variables (https://peps.python.org/pep-0008/#descriptive-naming-styles). But this can be done at a later date.

@mkavulich mkavulich closed this Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants