-
Notifications
You must be signed in to change notification settings - Fork 19
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
parse with Missing #61
Comments
Actually with JuliaLang/julia#23642 |
Close this issue then or keep for a reference? |
I'd say it depends on whether you think this syntax is needed or not. |
I believe we need a function that returns So let me comment on a use case and you can decide which way to go (I have much less understanding of the whole ecosystem context). A typical scenario with A pure approach would be to handle the missing data carefully, but a practical workflow (and this is how R works) is to parse it as Computer scientist now can do:
But data scientist has to do (or there is some simpler way?):
which not only is messy but also has wrong type ( I would like to have this fixed (I understand that solving |
I see your point. I'm not sure we want to follow R in all aspects, in particular we have the ability to distinguish an invalid value from a missing value, so it wouldn't be absurd to be stricter, and require an explicit operation to convert an unparsable value to a missing value. That could be done quite easily using |
Thanks. |
I also don't think But somewhat more conservative thing would be to allow parse(Int, missing) = missing
#= or =#
parse(Union{Int, Missing}, missing) = missing I prefer the first alternative as the 2nd might imply: Then it would be possible to |
The approach taken in |
@quinnj Do you also throw |
I don't currently have a use-case for that in CSV as there's always guaranteed to be an input, though the input may be an empty string. |
So you are using |
@nalimilan was that in response to my comment or @alyst ? |
To yours. |
No, the user has to provide, in the case of CSV, a "null" string and if the input matches this "null" string, then |
A user ran into this with I would recommend a keyword argument, but if a constructor relies on parsing, we have to trust that they forward keyword arguments as well. |
Since |
@nalimilan Right. Has a proposal / discussion started over there? Let's link to it if so. |
Actually I would close it (although I know I have raised the issue in the first place). The current meta-understanding of types in Base is the following AFAICT:
I would argue that But maybe there are cases when would be convenient to return |
Yes, the case for parsing to I'm not aware of any issue in Base about this currently. |
Yes - the sentinel approach could make sense. It could be also more general, e.g. allowing a Regex or a predicate. |
Having a |
@scls19fr - as you can see from the discussion above the issue is not that simple. What syntax would you think would be the most convenient while consistent (the consistency issue was a major concern in the past). |
parse and tryparse to handle missing/nothing, returning missing as result.
Added handling of missing/nothing inputs for parse and tryparse. Returns nothings to stay consistent with parse returns during invalid parses.
I think one should output nothing when using parse/tryparse on missing/nothing data. Since it's tryparse is already outputting nothing on invalid strings. Especially since nothing is suppose to represent "does not exist", so parsing missing/nothing should give a result that "does not exist". |
I would like to put under consideration if we want to add methods to
parse
that acceptUnion{T, Missing}
argument (or create a similar method). This would be something liketryparse
but returningmissing
on failure.I would think of something like:
parse(Union{Int, Missing}, "123") == 123
;parse(Union{Int, Missing}, "123a") == missing
.The text was updated successfully, but these errors were encountered: