Cannot pass empty grouping_mark to locale()

[peterdesmet]

Since the upgrade to readr 2.0.0 (or maybe other packages), the integer and number tests fail, specifically on the property bareNumber:

https://github.com/inbo/datapackage/blob/a195f686a86b46b6042966db69c3cc5ee2c7c237/tests/testthat/types.json#L70

The moment that property is added in the JSON file (whether true or false) it stalls any reading of the file. I haven't figured out why. bareNumber is handled here:

https://github.com/inbo/datapackage/blob/a195f686a86b46b6042966db69c3cc5ee2c7c237/R/read_resource.R#L337

[peterdesmet]

The issue is caused by passing an empty grouping_mark to locale, which is used by col_number().

[peterdesmet]

This is resolved by passing ♥ as grouping_mark: a non-empty, unlikely to occur value, see 26e7482:

This value is set to "♥" because it is unlikely to occur and will only be used for bareNumber=false with undefined grouping_mark. It is not set to "" because tidyverse/readr#1241 nor "," because that can conflict with non-default decimal_mark.

@damianooldoni please provide feedback? Should we revisit this when readr allows "" as grouping_mark again? Is that likely to happen?

[peterdesmet]

Ok, I'm getting:

Found the following file with non-ASCII characters:
    read_resource.R
  Portable packages must use only ASCII characters in their R code,
  except perhaps in comments.
  Use \uxxxx escapes for other characters.

Suggestions for other characters?

[damianooldoni]

I give it a look now

[damianooldoni]

I agree to give a non usual character for grouping mark, but still I would choose it within the characters you can find on a normak keyboard 😄
Why not setting it up to "~" for example? The usage of this character in a character column will never create any problem, as the grouping mark is only searched in numeric columns. So, we shouldn't go too exotic. Or am I missing something?

And what if a user specifies "~" as decimal mark, but no grouping mark? Then set "," as grouping mark instead, I would say.

[peterdesmet]

Thanks, I have opted for ¡ (upside-down !, ascii 173, 18023da), since ~ is more likely to occur in number fields as "approximately". I did not add code in case the user sets ¡ as decimal mark, as I rather have it display the default readr error:

Error: decimal_mark and grouping_mark must be different

Setting , as default (not user explicit) grouping mark can lead to unreported issues in barenumber=false.

[peterdesmet]

Correction, that was also extended ASCII. Now opted for backtick. Ideally, this should be reverted back to "" once readr allows it again.