-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-12630][Python][MLlib][DOC] Update param descriptions in classification.py #10598
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
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.
remove blank lines here, and around other "Allowed values"
|
thanks @vijaykiran! I marked a few things for correction and I think in general we should extend the comments to the 100 character limit where applicable. |
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.
nit: no period after the ending parenthesis in default line
|
@BryanCutler Thanks for the review, I added a new commit - will review update other two PRs with 100 fill-column as well. Do you prefer a squashed commit ? |
|
LGTM. It's not necessary to squash commits, but could you update the PR title/description to indicate that this is for PySpark MLlib classification? ping @jkbradley @mengxr |
|
I just added a note to the parent JIRA about a formatting issue affecting all 5 PRs: [https://issues.apache.org/jira/browse/SPARK-11219?focusedCommentId=15090225&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15090225] |
|
Hi @vijaykiran , will you be able to update the param descriptions to be only up to 74 character limit? Sorry for the mixup, but I think this should be mergable after that. |
178d0b3 to
517421d
Compare
|
ping @BryanCutler - Updated the param descriptions, can you take a look ? |
|
I viewed in pydoc with a window size of 80 and LGTM, cc @jkbradley to take a look. Thanks @vijaykiran! |
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 line is over the 74 char limit
|
@vijaykiran , I missed one line that is a bit too long, could you please fix that, otherwise LGTM |
Updates the `param` descriptions consistent. See [SPARK-11219] for more details.
- Style fixes based on review comments by @BryanCutler. - Changed fill-column to 100 instead of 80.
|
ping @BryanCutler @jkbradley - can you guys please take a look again? |
|
LGTM |
|
@vijaykiran @BryanCutler Please run Please test the other two PRs as well. Thanks! |
|
@mengxr thanks, will take a look today |
|
@vijaykiran Thanks! Please ignore the warnings from |
|
ok to test |
|
Test build #50152 has finished for PR 10598 at commit
|
|
@vijaykiran Could you fix the doc warnings in |
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.
It looks like we have a problem with the formatting of this param. If we want the html to look the same and get rid of any warnings, then I think it has to be written like this
:param regType:
The type of regularizer used for training our model.
:Allowed values:
- "l1" for using L1 regularization
- "l2" for using L2 regularization
- None for no regularization
(default: "l2")
which, I think, looks ugly in the code and not even that great in the html. Alternatively, we could rewrite it inline similar to how some other params have it, like this
:param regType:
The type of regularizer used for training our model.
Allowed values: "l1" for using L1 regularization;
"l2" for using L2 regularization; None for no
regularization.
(default: "l2")
Not perfect, but both code and html look decent, imho.
@mengxr , would you be ok with the second inline format?
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.
The first one looks better but no strong preference. I tried the following that also works:
:param regType:
The type of regularizer used for training our model.
Allowed values:
- "l1" for using L1 regularization
- "l2" for using L2 regularization (default)
- None for no regularization
Note Allow values is not a Sphinx keyword.
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.
It's not a huge deal so I'm ok with either, but my issue with the additional blank lines is that in the context of the already large param list, the extra blank lines seem like a little much and the rendered html looks sloppy to me too. Since I noticed other parts describing allowed values in a single paragraph, I thought maybe we should stick to that.
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.
If we use :Allowed values:, it shows up as :Allowed values: in html, which is weird. We should change existing ones instead of repeating the mistakes, in a separate PR. I don't think the rendered html changes due to that additional blank line. It is just control by top margin of a list, which could be configured via CSS. This is how it looks in html for my proposal, which looks good to me:
Let's quickly fix this one and merge this PR.
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 believe that :Allowed values: would need to be preceded by a blank line for Sphinx to interpret it in bold like before, but I don't think that needs to be done here. What @mengxr proposed above looks fine with me too.
@vijaykiran , will you be able to make this fix soon? I could take over and finish this last little bit if you can't.
|
Thanks for working on this @vijaykiran , I finished up the remaining fix in #11183 so please close this one up. |
|
@vijaykiran I merged #11183 into master. Do you mind closing this PR? Thanks! |

Updates the
paramdescriptions in python mllib's classification.py to be consistent. See [SPARK-11219] for moredetails.