<div dir="ltr"><div>> Replacing NaT with NA breaks arithmetic consistency</div><div><br></div><div>This means the result dtype of a Series & scalar, right? If so, it's worth deciding whether that's more valuable than consistency in the behavior of missing values in arithmetic and comparison operations.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 13, 2020 at 4:23 PM 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"><div>> This would also imply creating a nullable float dtype and making 
our datelikes use NA rather than NaT too. That seemed to be generally 
OK, but wasn't discussed too much.</div><div><br></div><div>My understanding of the discussion is that using a mask on top of datetimelike arrays would not _replace_ NaT, but supplement it with something semantically different.  Replacing NaT with NA breaks arithmetic consistency, as has been discussed ad nauseum.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 12, 2020 at 3:29 PM 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>Thanks Joris.</div><div><br></div><div>This was discussed on the call today: <a href="https://docs.google.com/document/d/1tGbTiYORHiSPgVMXawiweGJlBw5dOkVJLY-licoBmBU/edit?usp=sharing" target="_blank">https://docs.google.com/document/d/1tGbTiYORHiSPgVMXawiweGJlBw5dOkVJLY-licoBmBU/edit?usp=sharing</a>. I'll try to summarize the discussion here.</div><div><br></div><div>On NA by default, there were a few concerns, none of which is likely a blocker. Things like the memory overhead of masks can be improved by making them optional (relatively easy) and possibly using a bitmask (probably harder).</div><div><br></div><div>I wondered if this was blocked by the BlockManager being written in Python. This change would imply that blockwise ops would become columwise, so we'll have more overhead for some ops. Joris cited a bit of work he did to make this not too bad, at least for not too wide of tables.</div><div><br></div><div>I also wondered whether this would be inappropriate as long as NA lives in pandas, rather than something that is understood by the entire scientific python ecosystem. It's worth thinking about and seeing how the community reacts to NA. Probably not a blocker.</div><div><br></div><div>This would also imply creating a nullable float dtype and making our datelikes use NA rather than NaT too. That seemed to be generally OK, but wasn't discussed too much.</div><div><br></div><div>---</div><div><br></div><div>Other "2.0" topics included rethinking our dependencies. It's possible Arrow could be added. Going nullable by default would make Arrow a pretty attractive option for storing arrays. But we would need to consult with our downstream dependencies (like xarray) and users about that.</div><div><br></div><div>Fixing __getitem__ was also discussed. That will take someone to write up a detailed proposal about specific proposed changes and possible deprecation paths.</div><div><br></div><div>Tom<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 10, 2020 at 11:43 AM 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><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">pandas 1.0 is out, so time to start thinking about 2.0 ;)</p><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">In principle, pandas 2.0 will just be one of the next releases when we decide we want to clean-up the deprecations / make a few changes that are hard to deprecate (following our new versioning policy).<br>But nonetheless, I think it can still be interesting to think about it if it can also be something more than that, and have more specific goals in mind*.</p><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Last year I made the<span> </span>pd.NA<span> </span>proposal, which resulted in using that for the nullale integer, boolean and string dtypes. In the proposal,<span> </span>pd.NA<span> </span>was described as "can be used consistently across all data types". And for me, the aspirational end goal of this proposal is to<span> </span><i>actually</i><span> </span>have this for <i>all</i> dtypes, but we never really discussed this aspect explicitly.</p><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">So, for me, a possible future pandas 2.0:</p><ul style="margin-top:0.6em;margin-bottom:0.65em;padding-left:0px;margin-left:1.7em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><li style="margin-bottom:0.4em">Uses all "nullable dtypes" by default (i.e. dtypes that use<span> </span><code style="border:1px solid rgb(220,220,220);background-color:rgb(243,243,243);padding-right:0.2em;padding-left:0.2em;border-radius:0.25em;color:rgb(0,0,0);font-size:0.9em">pd.NA</code><span> </span>as missing value indicator). That means we add a nullable version of all other dtypes (as we now already did for int, boolean, string). End goal: a single missing value indicator with the same behavior for all dtypes.</li><li style="margin-bottom:0.4em">If we add such nullable dtypes using the extension dtypes/array mechanism (so it can first be opt-in in 1.X), this could "automatically" lead to a simplification of the internals / Block Manager (another aspirational goal that has been discussed before, but never became concrete). Because in such a case (all extension dtypes), we would only be using 1D blocks (simplifying the 1D / 2D thorny cases in internals). This simplifies the memory model, consolidation, etc</li></ul><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Do you think this is a desirable goal? And realistic? Other aspirational goals?<br></p><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Best,<br>Joris</p><p style="margin-top:0.6em;margin-bottom:0.65em;color:rgb(34,34,34);font-family:Avenir,Arial,sans-serif;font-size:15px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">*Agreeing on goals doesn't mean it will happen, that's open source (or at least community-based open source). But I think it can still be useful to guide some efforts where possible or in trying to get traction for certain issues from contributors. And then we can still see if it gets done in 2.0, 3.0, 4.0 or never ;)</p></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>
_______________________________________________<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>