-
Notifications
You must be signed in to change notification settings - Fork 14
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
better validation of inputs to Deconfounders #20
Comments
I totally agree. Maybe we could drop the None value as default for y in both functions, and then add an if condition to raise an error if a second argument is not passed, something like this:
This, and a better clarification in the documentation. |
In fact, we should not even call it Also, if we stop caring about sklearn, we can even get rid of addtitional layers of calls |
100% agreed. That would avoid misinterpretations. Also, if we are going to stop caring about sklearn, and this is just a matter of personal preference, I would require X and C to be passed by their keyword, e.g. doing |
Good idea, I think that should be possible, let me double check how to enforce it (or please share if you know the details already). btw, would you want to take a crack at this? :) |
Sure Pradeep. This is what I was referring to. Let's take the example for Residualize:
As you can see, I changed the name of
it will give you an error, because you now have to pass things by their keyword, not their position. That is, you have to write the following to work:
It's more wordy, but less prone to errors in my opinion, as the user explicitly knows what they are passing to the functions. |
thanks Javier - can you link me to some docs on the how this |
Maybe this could work? https://python-3-for-scientists.readthedocs.io/en/latest/python3_advanced.html |
I see, thanks. but that would allow weird behaviour like |
No, but that's not possible, Pradeep. Users will still be able to pass only two arguments, in this case I know that using keyword-only arguments might not be standard, but I find it more clear, particularly in our case in which the order logic of the input data and covariates do not follow as straightforward as in the usual sklearn scenario (input data/target). Anyway, it was just a suggestion and can be easily changed at any moment in the future if wanted. For example, if we see that users find the current behaviour confusing. We need tester users :-) |
I like the idea, just want to make sure there will be no side effects etc |
Pradeep, I've made a little progress today on this issue, but there's something that we need to decide before I carry on pushing my changes. If we finally decide to give an error if the second input argument in If we finally do this, we could also remove lines like these in base.py, which were particularly included to pass the mentioned test
Line 162 in 7c3c475
|
sounds good - we can do whatever is needed to achieve our objectives. Let's discuss this when we discuss the other PR #21 too? |
sound good! |
the #19 reminds me of how some users can be confused given the code lets the second argument to
.fit()
and.transform()
optional withy=None
. The only reason we havey=None
is to try follow sklearn conventions and to pass their tests, but given we can't pass them anyway, we should tighten them up and make it an error to not supply the second [necessary] input argument.cc @jrasero @jameschapman19
The text was updated successfully, but these errors were encountered: