-
Notifications
You must be signed in to change notification settings - Fork 10
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
Bnb/h5 with era training #162
Conversation
671eee9
to
761e8e1
Compare
sup3r/bias/bias_calc.py
Outdated
shape=self.shape, | ||
val_split=0.0, | ||
**bias_handler_kwargs, | ||
) |
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.
Did you run an auto formatter on everything? Do you like this style better and why? Some thoughts: The original formatting has strong horizontal separation of the output var, method, and input args. In the original formatting, it's very clear which lines are part of the function call. In the new formatting, it's more difficult to visually separate the output arg from the input args. Lastly, what is the logic for having the closing parenthesis on the 0 column? It's closing the function call, not the original line?
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.
@bnb32 it looks like some of the files are still black-formatted. Are you going to revert this or are we going with the black style?
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.
Ah, I missed some. I have to revert manually which I will do if you want. Although after playing around with a bunch of formatters since the start of this discussion I now like black even more :)
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.
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.
Yeah I'm not a fan of that formatting either but I don't think it's that frequent and I personally consider the consistency a net positive. I think
out_arg = func(
input_args
)
is quite readable in general though.
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 think it's a step backwards as far as code standards but if you want to do it for this repo i'll leave that decision to you. I think it's worst with massive chained "one-liners" like in the screenshot above. Basically i think this moves the onus to the developer to write smaller function chains to get more sensible code (e.g., split up the code above into 3-4 single lines that are actually single lines). IMO we should have better standards than in the example above. If we do want to do black across the board, i recommend adding the github action: https://github.com/marketplace/actions/run-black-formatter
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.
Do you think that onus is a bad one? I think the example above is the worst and for 99% the readability is maintained or improved tbh. I've turned off black formatting though since I don't want to enforce something you don't like, but I'd prefer not to have to manually revert a ton.
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 think moving the focus onto a different type of style is bad. I do think black makes some code more readable and some other code much less so. I guess it just goes to show that these tools won't automatically transform any code into "good" code. There's still a lot of human considerations the developer has to work with to make readable code.
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.
Definitely agree!
aa8cff8
to
feea8c0
Compare
np.maximum(0, (self.strategy.spatial_pad - s1_start))) | ||
pad_s1_end = (self.strategy.spatial_pad + s1_stop | ||
- self.strategy.grid_shape[0]) | ||
pad_s1_end = int(np.maximum(0, pad_s1_end)) |
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.
Thank you! 🙌
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.
Sure thing!
feea8c0
to
a2f5399
Compare
Bnb/h5 with era training
No description provided.