Open gdementen opened 2 years ago
@alixdamman: What are your thoughts on this? If you agree with my reasoning, I will not better document the fill_value argument (i.e. I will simply close issue #1020) but rather change its meaning instead (for release 0.35).
I think we should implement this, and if somebody ever wants to have a different behavior for the two cases, we could implement a new missing_combination_fill_value (or whatever we would call it) argument at that point.
Yes, it is the best solution to me. I agree with you.
FWIW, bm stumbled on this too
As a follow-up to #1020, I wonder if we shouldn't make the
fill_value
argument ofread_*
also replace nans by the fill_value.I think this is what users actually want in most cases, but if we implement this, users will not any more be able to get a different behavior for "existing labels but nan value" than for "missing label combination" (current fill_value semantic). But is there a use case for this? I do not see it, but if there is, implementing this would be annoying for them.
FWIW, Pandas does not do nan-to-value changes but they do not need the
fill_value
argument either.I think we should implement this, and if somebody ever wants to have a different behavior for the two cases, we could implement a new
missing_combination_fill_value
(or whatever we would call it) argument at that point.