<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 20 Feb 2020 at 00:52, Brock Mendel <<a href="mailto:jbrockmendel@gmail.com">jbrockmendel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Pivoting: Joris, on the call you mentioned a TimestampArray.  Can you expand on that a bit?<br></div></blockquote><div><br></div><div>Basically what I mentioned before in this thread: a new ExtensionArray that uses pd.NA as missing value indicator instead of pd.NaT, and where the NAs are potentially tracked in a mask (as done for the nullable integer dtypes). <br></div><div>There are more things about it (like allowing more resolutions? single dtype for tz-naive/tz-aware? ..), but I will try to open a separate discussion going more in depth about this shortly.</div><div><br></div><div>But, the issue for NA vs NaT is somewhat similar as NA vs NaN, for which I just opened an issue to further discuss this in more detail: <a href="https://github.com/pandas-dev/pandas/issues/32265">https://github.com/pandas-dev/pandas/issues/32265</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 19, 2020 at 2:55 PM Joris Van den Bossche <<a href="mailto:jorisvandenbossche@gmail.com" target="_blank">jorisvandenbossche@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 18 Feb 2020 at 18:20, Tom Augspurger <<a href="mailto:tom.augspurger88@gmail.com" target="_blank">tom.augspurger88@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 17, 2020 at 7:17 PM Brock Mendel <<a href="mailto:jbrockmendel@gmail.com" target="_blank">jbrockmendel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>> You have no problem with changing the behavior of NaT, or changing to use pd.NA?</div><div><br></div><div>If/when we get to a point where we propagate NAs in all other comparisons, I would have no problem with editing `NaT.__richcmp__` to match that convention.<br></div></div></blockquote><div><br></div><div>What are the advantages of a NaT with NA-like comparison semantics over using NA<br>(or NA[datetime])?<br><br>1. Retain dtype in array - scalar ops with a scalar NA<br>2. ...</div><div>3. Less disruptive than changing to NA<br></div><div><br>My ... could include things like `isinstance(NaT, Timestamp)` being true and<br>`NaT.<attr>` for Timestamp attributes. But those don't strike me as necessarily<br>good things. They seem sometimes useful and sometimes harmful.<br><br>The downside of changing NaT in comparison operations are<br><br>1. We're diverging from `np.NaT`. I don't know how problematic this actually is.<br>2. It's a special case. Should users need to know that datelikes use their own<br>   NA value because the underlying storage is able to store them "in-band"<br>   rather than as a mask? My gut reaction is "no, users shouldn't be exposed to<br>   this."<br>3. Changing NaT would leave just NaN with the "always unequal in comparisons"<br>   behavior.<br></div></div></div></div></blockquote><div><br></div><div>Personally, I think changing the behaviour of NaT in pandas, and thus deviating from the behaviour of the same value in numpy, is not a good idea. For me, that seems more confusing than having a clearly distinct value (pd.NA) that has the different behaviour.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote"><div dir="ltr"><div class="gmail_quote"><div><br>Thus far, I see three options going forward<br><br>1. Use NaN for floats, NaT for datelikes, NA for other.<br>  1-a: Leave NaT with always unequal<br>  1-b: Change NaT to have NA-like comparison behavior<br>2. Use NA everywhere (no NaN for float, no NaT for datelike<br>3. Implement a typed `NA<T>`, where we have an `NA` per dtype.<br><br>Option 3 I think solves the array - scalar op issue. It's more complex for users<br>though hopefully not too complex? My biggest worry is that it makes the<br>implementation much more complex, though perhaps I'm being pessimistic.<br><br>On balance, I'm not sure where I come down yet. Good news: we can take time to<br>figure this out :)<br></div></div></div></div></div></div></blockquote><div><br></div><div>Thanks for the summary! <br></div><div>Personally, I don't like the first option *long term* as it keeps different missing values (eg NaN) with different behaviours for some dtypes as default, while I would like to see us moving to a consistent missing value indicator. <br></div><div>And I think we can take a similar approach as we somewhat decided in the original discussion on pd.NA: let's start with a single pd.NA, and we can see later if there is a need to make it typed.</div><div><br></div><div>Joris<br></div><div> </div></div></div>
_______________________________________________<br>
Pandas-dev mailing list<br>
<a href="mailto:Pandas-dev@python.org" target="_blank">Pandas-dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/pandas-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/pandas-dev</a><br>
</blockquote></div>
</blockquote></div></div>