-
Notifications
You must be signed in to change notification settings - Fork 28.6k
[SPARK-31571][R] Overhaul stop/message/warning calls to be more canonical #28365
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
@@ -431,7 +431,7 @@ setMethod("coltypes", | |||
if (is.null(type)) { | |||
specialtype <- specialtypeshandle(x) | |||
if (is.null(specialtype)) { | |||
stop(paste("Unsupported data type: ", x)) | |||
stop("Unsupported data type: ", x) |
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.
here, paste
was creating an extra space, now fixed
add to whitelist |
ok to test |
Test build #121897 has finished for PR 28365 at commit
|
Test build #121900 has finished for PR 28365 at commit
|
cc @felixcheung and @shivaram FYI |
Test build #121941 has finished for PR 28365 at commit
|
Not sure why the Documents task failed, looks like the |
Sure, but, what about the 1000s in the JVM code this calls too? a little translation isn't going to help anyway. Think about maintaining translations for new messages. I don't think it will be worth it, so wouldn't make changes only to support it. |
I would leave the JVM stuff to the developers working more closely with that code base. Translations only have to be updated at release time & the marginal cost from release to release would generally be low. Anyway let's table that since you're right it's a bit premature. I'll split off the gettextf changes in a while |
R/pkg/R/DataFrame.R
Outdated
"outer", "full", "fullouter", "full_outer", | ||
"left", "leftouter", "left_outer", | ||
"right", "rightouter", "right_outer", | ||
"semi", "left_semi", "leftsemi", "anti", "left_anti", "leftanti")) { | ||
"semi", "left_semi", "leftsemi", "anti", "left_anti", "leftanti") |
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.
noting here that i changed this error message slightly (removed the or and aligned the ordering (leftsemi/left_semi and leftanti/left_anti are swapped vis-a-vis the %in% condition).
it may be preferable to just change the test not to be so exact. LMK
@HyukjinKwon have reverted all |
Test build #122025 has finished for PR 28365 at commit
|
Test build #122031 has finished for PR 28365 at commit
|
Test build #122037 has finished for PR 28365 at commit
|
Test build #122040 has finished for PR 28365 at commit
|
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 it's just improving the code, seems fine.
Test build #122085 has finished for PR 28365 at commit
|
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.
Looks okay but would need a closer look from me or somebody else.
@@ -354,8 +354,8 @@ varargsToStrEnv <- function(...) { | |||
} else { | |||
value <- pairs[[name]] | |||
if (!(is.logical(value) || is.numeric(value) || is.character(value) || is.null(value))) { | |||
stop(paste0("Unsupported type for ", name, " : ", class(value), | |||
". Supported types are logical, numeric, character and NULL."), call. = FALSE) | |||
stop("Unsupported type for ", name, " : ", toString(class(value)), ". ", |
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.
Quick question, why do we need to do toString
? Were there any differences at stop(paste(..., ...))
vs stop(..., ...)
?
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.
stop
uses sep=''
, so stop(paste0(...))
is equivalent to stop(...)
toString
collapses in cases length>1
, compare:
stop(toString(class(Sys.time())))
stop(class(Sys.time()))
Test build #122167 has finished for PR 28365 at commit
|
…ical ### What changes were proposed in this pull request? Internal usages like `{stop,warning,message}({paste,paste0,sprintf}` and `{stop,warning,message}(some_literal_string_as_variable` have been removed and replaced as appropriate. ### Why are the changes needed? CRAN policy recommends against using such constructions to build error messages, in particular because it makes the process of creating portable error messages for the package more onerous. ### Does this PR introduce any user-facing change? There may be some small grammatical changes visible in error messaging. ### How was this patch tested? Not done Closes #28365 from MichaelChirico/r-stop-paste. Authored-by: Michael Chirico <[email protected]> Signed-off-by: HyukjinKwon <[email protected]> (cherry picked from commit f53d8c6) Signed-off-by: HyukjinKwon <[email protected]>
Merged to master and branch-3.0. |
…ical ### What changes were proposed in this pull request? Internal usages like `{stop,warning,message}({paste,paste0,sprintf}` and `{stop,warning,message}(some_literal_string_as_variable` have been removed and replaced as appropriate. ### Why are the changes needed? CRAN policy recommends against using such constructions to build error messages, in particular because it makes the process of creating portable error messages for the package more onerous. ### Does this PR introduce any user-facing change? There may be some small grammatical changes visible in error messaging. ### How was this patch tested? Not done Closes apache#28365 from MichaelChirico/r-stop-paste. Authored-by: Michael Chirico <[email protected]> Signed-off-by: HyukjinKwon <[email protected]>
What changes were proposed in this pull request?
Internal usages like
{stop,warning,message}({paste,paste0,sprintf}
and{stop,warning,message}(some_literal_string_as_variable
have been removed and replaced as appropriate.Why are the changes needed?
CRAN policy recommends against using such constructions to build error messages, in particular because it makes the process of creating portable error messages for the package more onerous.
Does this PR introduce any user-facing change?
There may be some small grammatical changes visible in error messaging.
How was this patch tested?
Not done