-
Notifications
You must be signed in to change notification settings - Fork 3
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
some new features because south america #46
base: dev
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand mt so I feel weirdly unqualified to do code reviews. I mean, yeah, I ported the thing to python 3, but mostly that was an automated process wherein I ran some tests and didn't get into the internals much.
So this is more an advisory review, things I'd change even though I recognize my position of relative ignorance.
step['nout'] = step['nin'] | ||
try: | ||
step['nyrout'] = int(mod.get_nyrout(step['nyrin'], step['params'])) | ||
except: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to catch a specific exception type for safety.
Optional: Also, exceptions that pass silently are pretty rare; consider emitting a message to the user even if you don't re-raise.
if 'nin' in step: | ||
assert step['nin'] == thisnin, "Number of inputs do not match" | ||
else: | ||
step['nin'] = thisnin | ||
if 'nyrin' in step: | ||
assert step['nyrin'] == thisnyrin, "Number of years do not match" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would happen if the user disabled assertions when running this? That's how to tell if it should be a raise ValueError
instead.
# secret way to test | ||
results = [func(jobs[-nproc-1])] | ||
else: | ||
raise Exception("nproc can't be zero") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't Exception
, this is ValueError
. Never raise Exception; either pick a subtype or make a new one.
|
||
|
||
@pytest.mark.parametrize("nproc", [1, 2]) | ||
def test_passthrough2(nproc, tmpdir): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copypasta is bad. Extend the parametrization scheme instead so the existing test covers more cases.
Also, if you do, then test_passthrough2
is going away as a name, but know that it's a much better idea to name your tests verbosely so people can see what went wrong in test reports. Long, sloppy names aren't so bad for tests, eg, test_passthrough_this_time_with_weird_regex
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PS you can instead move some common code into a fixture and call it from both, if the two tests are different enough to warrant it.
shifttime.pyx module in case the season starts at a weird time
trimyr.pyx module because shifttime can result in a trailing useless year (also could consider an option to shifttime, but this seemed potentially useful
Modules can now change the number of years they output (nyrout), e.g. trimyr.pyx
Regex can now contain a group besides the date, but if so, they need to be labeled (backwards compatible), in our use case that group is used to handle data from different locations mixed in the same directory