-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-17116][Pyspark] Allow parameters to be {string,value} dict at runtime #15871
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
Conversation
|
@srowen @jaceklaskowski Could you take a look and check if this improvement is proper? Since this is my first contribution it might have some issues. 😅 |
|
Can one of the admins verify this patch? |
python/pyspark/ml/base.py
Outdated
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.
Shouldn't we just use isinstance instead?
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.
@HyukjinKwon I tried using isinstance(type(params.keys()[0],str) but it returned False. And why cant we directly check if it is a str or not?
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 meant, isinstance(params.keys()[0], str). Direct type comparison does not take care of subclasses. I believe it is a common pattern to check the types. For example,
>>> class A(str):
... pass
...
>>> isinstance(A(), str)
True
>>> type(A()) is str
FalseThis might be a major problem in a way, for example, when you give an argument as OrderedDict which extends dict.
Another reason is consistency across codebase. I believe isinstance is more widely used in the codes.
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.
@HyukjinKwon Ah I get you. I will make the changes
|
I think we need a test here maybe and update the argument description if this change is legitimate. |
|
cc @holdenk |
|
@HyukjinKwon this is my first time with contributing in Spark and so I didnt know if we add tests to each pull. If it is proper I will add the tests :) |
|
@HyukjinKwon @holdenk @srowen I have updated the code. Could you please take a look |
| for param, value in params.items(): | ||
| p = getattr(self, param) | ||
| param_new.update({p: value}) | ||
| params=param_new |
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.
Could we just make it just like the one as below?
params = dict([(getattr(self, p), v) for p, v in params.items()])BTW, I am not supposed to decide what should be added into Spark. We can wait for committer's review :)
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.
@HyukjinKwon Ok sure.
|
Thanks for working on this! So at first glance I'm not super sure if we want to add this (is this being done to be more closely related to the skicitlearn apis or something?) A good next step would probably be adding some tests for this as well :) Once we've got some tests we can ping some of the Python ML people and see what they think. |
|
@holdenk Sure. I will add the tests. I saw that as per the issue opened the setParams was taking in string dict while fit() method was not. Hence I thought it would be an improvement to do that to the fit() method as well. |
|
@aditya1702 - thanks that sounds like a good reason for us to be consistent between the two. Let me know how adding the tests goes :) |
|
Hi @aditya1702, do you mind if I ask whether you are still working on this? Maybe it should be closed for now if you are currently not able to work on this further. It seems inactive for few months. |
## What changes were proposed in this pull request? This PR proposes to close stale PRs. What I mean by "stale" here includes that there are some review comments by reviewers but the author looks inactive without any answer to them more than a month. I left some comments roughly a week ago to ping and the author looks still inactive in these PR below These below includes some PR suggested to be closed and a PR against another branch which seems obviously inappropriate. Given the comments in the last three PRs below, they are probably worth being taken over by anyone who is interested in it. Closes apache#7963 Closes apache#8374 Closes apache#11192 Closes apache#11374 Closes apache#11692 Closes apache#12243 Closes apache#12583 Closes apache#12620 Closes apache#12675 Closes apache#12697 Closes apache#12800 Closes apache#13715 Closes apache#14266 Closes apache#15053 Closes apache#15159 Closes apache#15209 Closes apache#15264 Closes apache#15267 Closes apache#15871 Closes apache#15861 Closes apache#16319 Closes apache#16324 Closes apache#16890 Closes apache#12398 Closes apache#12933 Closes apache#14517 ## How was this patch tested? N/A Author: hyukjinkwon <[email protected]> Closes apache#16937 from HyukjinKwon/stale-prs-close.
What changes were proposed in this pull request?
This pull allows a dictionary containing string as keys to be passed in the fit() method. Presently it only allows an instance of the Estimator to be passed as key.
How was this patch tested?
This patch was manually tested on a local PC.