trevorld / r-argparse

command-line optional and positional argument parser
GNU General Public License v2.0
103 stars 11 forks source link

"numeric" as an alias for the "double" "type" #42

Closed dariober closed 1 year ago

dariober commented 1 year ago

Would it be useful to add "numeric" to the data types supported by argparse? For example:

parser <- ArgumentParser()
parser$add_argument('--foo', type='numeric')

Fails with:

Error in get_python_type(type, proposed_arguments) : 
  type numeric not supported, supported types: 'logical', 'integer', 'double' or 'character'

I guess an R user would expect it to work since there exist functions like is.numeric, as.numeric, and class(1.2) returns "numeric". (On the other hand, typeof(1.2) returns "double").

See also numeric docs:

numeric is identical to double. It creates a double-precision vector of the specified length with each element equal to 0. ... It is a historical anomaly that R has two names for its floating-point vectors, double and numeric (and formerly had real).


Once again, thanks for supporting this great package and responding quickly to users!

sessionInfo()
R version 4.1.3 (2022-03-10)
Platform: x86_64-conda-linux-gnu (64-bit)
Running under: Ubuntu 18.04.5 LTS

Matrix products: default
BLAS/LAPACK: /home/dario/miniconda3/envs/tritume/lib/libopenblasp-r0.3.20.so

locale:
 [1] LC_CTYPE=en_GB.UTF-8       LC_NUMERIC=C               LC_TIME=en_GB.UTF-8        LC_COLLATE=en_GB.UTF-8     LC_MONETARY=en_GB.UTF-8   
 [6] LC_MESSAGES=en_GB.UTF-8    LC_PAPER=en_GB.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] argparse_2.1.6

loaded via a namespace (and not attached):
[1] compiler_4.1.3   R6_2.5.1         findpython_1.0.7 jsonlite_1.8.0 
trevorld commented 1 year ago

Although "numeric" is technically not an R "type" I guess there wouldn't be harm in supporting "numeric" as an alias for "double".