Better handling of int64 #706
Conversation
|
@eitsupi @sorhawell I'm not sure this is the right way to address the int64 issue but it works, what do you think? Note that I took |
There was a problem hiding this comment.
Thank you for working on this.
But I think we should not set options here with pl$set_options(), but use R's standard options() function.
The options function is widely used, and its usage such as temporary switching with something like withr is popular.
arrowusesarrow.int64_downcast
https://github.com/apache/arrow/blob/55afcf0450aa2b611e78335bdbfd77e55ae3bc9f/r/src/array_to_vector.cpp#L1307-L1314
I'd like to continue this discussion but this is out of scope for this PR. Can you open an issue for this?
This name is associated with TRUE/FALSE (do we downcast int64? yes or no). Here we have more choices so I don't think this name is suitable. |
Done #713
Of course I am not suggesting that it should be named as such, just an example of the use of the options function. |
Merge branch 'handle-int64' of https://github.com/pola-rs/r-polars into handle-int64 # Conflicts: # NEWS.md
Fine for me, I changed both the value "float" and the arg name |
|
I would like to have @sorhawell's opinion before merging |
| "acceptable_choices" = "`int64_conversion ` must be one of \"float\", \"string\", \"bit64\".", | ||
| "bit64_is_attached" = "Package `bit64` must be attached to use `int64_conversion = \"bit64\"`." |
There was a problem hiding this comment.
How about use raw strings here?
There was a problem hiding this comment.
I don't think it would add much
Close #465