search for: colconvert

...e: > Hey, > > In the meantime, I submitted a bug. Thanks for the assistence on that. > > > and I'm not convinced that > > coercion failures should fallback gracefully to the default. > > the gracefull fallback: > - makes the code more complex > + keeps colConvert implementations limited > + requires the user to only implement what changed from the default > + seemed to me to smallest overall effort > > In my opinion, gracefull fallback makes the thing better, > but without it, the colConvert parameter remains usefull, it would still > fill...

...n the meantime, I submitted a bug. Thanks for the assistence on > that. > > and I'm not convinced that > > coercion failures should fallback gracefully to the default. > the gracefull fallback: > - makes the code more complex > + keeps colConvert implementations limited > + requires the user to only implement what changed from the default > + seemed to me to smallest overall effort > In my opinion, gracefull fallback makes the thing better, > but without it, the colConvert parameter remains usefull, it would...

...parameter to readtable. The function is called for every column. The goal is to allow specific (non-standard) type conversions depending on the input. When the parameter is not given, or the function returns NULL, the legacy default applies. The colClasses parameter still takes precedence, i.e. the colConvertFn only applies to the default conversions. This allows to properly load a .csv with timestamps expressed in the (quite common) %d/%m/%y %H:%M format, which was impossible since overruling as.POSIXlt makes a copy in the users namespace, and read.table would still take the base version of as.POSIXlt....

This has some nice properties: 1) It self-documents the input expectations in a similar manner to colClasses. 2) The implementation could eventually "push down" the coercion, e.g., calling it on each chunk of an iterative read operation. The implementation needs work though, and I'm not convinced that coercion failures should fallback gracefully to the default. Feature requests

Hey, In the meantime, I submitted a bug. Thanks for the assistence on that. > and I'm not convinced that > coercion failures should fallback gracefully to the default. the gracefull fallback: - makes the code more complex + keeps colConvert implementations limited + requires the user to only implement what changed from the default + seemed to me to smallest overall effort In my opinion, gracefull fallback makes the thing better, but without it, the colConvert parameter remains usefull, it would still fill a gap. > The implemen...