-
Notifications
You must be signed in to change notification settings - Fork 390
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
Fix small bug in _get_params_callbacks #969
base: master
Are you sure you want to change the base?
Conversation
Swap the order of default callbacks and current callbacks in _get_params_callbacks We want the default callbacks first, so that the current callbacks can override them. The fixed code now matches _yield_callbacks.
Thanks for the PR, the change seems reasonable :) It would be perfect if you could add a test that tests the desired effect (i.e. overriding of a default callback)! |
Thanks for the fix. As githubnemo mentioned, it would be nice to have a test (also, an entry to CHANGES.md).
For my understanding, is the idea for the user to have a callback with the same name as one of the default callbacks (say, |
@BlackHC Would you be willing to address the point? Otherwise, we would probably create a separate PR (still crediting you). |
I will have a look this week. Sorry for the delays. I was traveling for a conference and took some time off. Yes, the idea was to be able to override default callbacks as well and to also match the existing behavior in other methods (to avoid subtle bugs in the future). I'll try to write tests for this that cover both _get_params_callbacks and _yield_callbacks hopefully to make sure that they stay in sync. Best wishes, |
Fantastic, thanks @BlackHC. No time pressure, I just wasn't sure if you were still interested in working on this. |
@BlackHC a friendly reminder. |
I have taken another look at this. Is the canonical way to disable a callback similar to: Writing a test, I realized that |
This is using the same idea as in sklearn
(docs) Although it seems that we should also allow
Hmm, I was taking a stab and I think that the initial concern, namely:
is not really a concern, since skorch will raise an error if a callback name is duplicated. Honestly, it's something that I personally never had a use for, so I forgot about it. I guess we could still argue that the proposed change is "more correct" and write a test that checks the order of the returned params, but I agree it's not super useful.
Yes indeed. Is that something you're interested in working on? |
Swap the order of default callbacks and current callbacks passed to
itertools.chain
in _get_params_callbacks.We want the default callbacks first so that the current callbacks can override them. The fixed code now matches the order in _yield_callbacks.