Implement _most_ of the EA interface for DTA/TDA
State: closed

@TomAugspurger as promised, this implements a handful of tests, and a few more can be ported from #23415, but the EA-specific tests haven't been started.

The big missing piece is DatetimeArray._from_sequence, which I'm getting started on now in a new branch.

Closes #23586

Labels:
name: Datetime
description: Datetime data dtype
name: ExtensionArray
description: Extending pandas with custom dtypes or arrays.

Comments:
Hello @jbrockmendel! Thanks for updating the PR.

 - There are no PEP8 issues in the file [`pandas/core/arrays/datetimelike.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/arrays/datetimelike.py) !

 - There are no PEP8 issues in the file [`pandas/core/arrays/datetimes.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/arrays/datetimes.py) !

 - There are no PEP8 issues in the file [`pandas/core/arrays/period.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/arrays/period.py) !

 - There are no PEP8 issues in the file [`pandas/core/arrays/timedeltas.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/arrays/timedeltas.py) !

 - There are no PEP8 issues in the file [`pandas/core/indexes/datetimelike.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/indexes/datetimelike.py) !

 - There are no PEP8 issues in the file [`pandas/core/indexes/datetimes.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/core/indexes/datetimes.py) !

 - There are no PEP8 issues in the file [`pandas/tests/arrays/test_datetimelike.py`](https://github.com/jbrockmendel/pandas/blob/0fb5029a176f9802d4e4e4b41be32bb197eefa12/pandas/tests/arrays/test_datetimelike.py) !



##### Comment last updated on November 12, 2018 at 20:25 Hours UTC
Ported the last of the relevant tests from #23415
@TomAugspurger are you still good taking this PR over?  (BTW Travis failures look like unrelated timeouts)
Sure will push changes here.
Ah, I see what you mean now. Yes you're right.

And I suppose we can't even assume that concatenating multiple
DatetimeArrays with the same
freq will end up with a DatetimeIndex with the same freq.

On Tue, Nov 13, 2018 at 2:34 PM Joris Van den Bossche <
notifications@github.com> wrote:

> *@jorisvandenbossche* commented on this pull request.
> ------------------------------
>
> In pandas/core/arrays/datetimelike.py
> <https://github.com/pandas-dev/pandas/pull/23643#discussion_r233211534>:
>
> > +        raise AbstractMethodError(self)
> +
> +    def take(self, indices, allow_fill=False, fill_value=None):
> +        if allow_fill:
> +            fill_value = self._validate_fill_value(fill_value)
> +
> +        new_values = take(self.asi8,
> +                          indices,
> +                          allow_fill=allow_fill,
> +                          fill_value=fill_value)
> +
> +        return type(self)(new_values, dtype=self.dtype)
> +
> +    @classmethod
> +    def _concat_same_type(cls, to_concat):
> +        # for TimedeltaArray and PeriodArray; DatetimeArray overrides
>
> Sorry, that's not what I was meaning. The difference is the meaning of
> freq for PeriodArray vs DatetimeArray. For PeriodArray it is part of the
> dtype and it is defining how the stored integers are interpreted (and thus
> need to match to just concatenate those integers), but for DatetimeArray it
> is simply an informative attribute telling you about the regularity of the
> Array, but not essential to describe it. So I would assume that
> _concat_same_type needs to handle different arrays with different freqs
> for DatetimeArray.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/23643#discussion_r233211534>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABQHIphnpyu5IlWltCDwJywVRHis1KMFks5uuyzTgaJpZM4YaMQT>
> .
>

> And I suppose we can't even assume that concatenating multiple DatetimeArrays with the same freq will end up with a DatetimeIndex with the same freq.

Indeed, as that would only be the case if they are nicely consecutive ranges.
Pushed some changes.

1. DatetimelikeArray.copy now copies the underlying data
2. changed the concatenation of DatetimeIndex, hopefully for the better.
# [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=h1) Report
> Merging [#23643](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/a197837c4067469478b13e491a21b58cb78ed165?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `98.48%`.

[![Impacted file tree graph](https://codecov.io/gh/pandas-dev/pandas/pull/23643/graphs/tree.svg?width=650&token=eZ4WkYLtcO&height=150&src=pr)](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master   #23643      +/-   ##
==========================================
+ Coverage   92.24%   92.24%   +<.01%     
==========================================
  Files         161      161              
  Lines       51318    51340      +22     
==========================================
+ Hits        47339    47361      +22     
  Misses       3979     3979
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.64% <98.48%> (ø)` | :arrow_up: |
| #single | `42.34% <45.45%> (+0.03%)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/core/arrays/datetimelike.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL2RhdGV0aW1lbGlrZS5weQ==) | `96.14% <100%> (+0.21%)` | :arrow_up: |
| [pandas/core/arrays/period.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL3BlcmlvZC5weQ==) | `98.44% <100%> (-0.05%)` | :arrow_down: |
| [pandas/core/arrays/timedeltas.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL3RpbWVkZWx0YXMucHk=) | `95.63% <100%> (+0.55%)` | :arrow_up: |
| [pandas/core/indexes/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9kYXRldGltZXMucHk=) | `96.11% <100%> (-0.01%)` | :arrow_down: |
| [pandas/core/dtypes/concat.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvZHR5cGVzL2NvbmNhdC5weQ==) | `96.66% <100%> (+0.4%)` | :arrow_up: |
| [pandas/core/arrays/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL2RhdGV0aW1lcy5weQ==) | `98.47% <100%> (+0.03%)` | :arrow_up: |
| [pandas/core/indexes/datetimelike.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9kYXRldGltZWxpa2UucHk=) | `97.74% <85.71%> (-0.28%)` | :arrow_down: |
| [pandas/tseries/offsets.py](https://codecov.io/gh/pandas-dev/pandas/pull/23643/diff?src=pr&el=tree#diff-cGFuZGFzL3RzZXJpZXMvb2Zmc2V0cy5weQ==) | `96.98% <0%> (-0.09%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=footer). Last update [a197837...3cb072e](https://codecov.io/gh/pandas-dev/pandas/pull/23643?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).

just a really minor comment. ok to merge.
Going to leave the stale comment for now if that's OK. That whole if / else should be going away soon.
ok! thanks @jbrockmendel and @TomAugspurger