REF: Simplify Period/Datetime Array/Index constructors
Split off from the same branch that spawned #23083.

Hello @jbrockmendel! Thanks for submitting the PR.

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

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

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

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

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

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

 - There are no PEP8 issues in the file [`pandas/tests/indexes/period/test_construction.py`](https://github.com/jbrockmendel/pandas/blob/0e40ed42c7439d4b8e0c6680f5aaa5c30a64c6d0/pandas/tests/indexes/period/test_construction.py) !

 Also, to what extent is not conflicting with the work @TomAugspurger is doing in the PeriodArray PR? I haven't looked through this yet, but the constructors are a major pain
point on that PR right now.

On Thu, Oct 11, 2018 at 1:00 PM Joris Van den Bossche <
notifications@github.com> wrote:

> Also, to what extent is not conflicting with the work @TomAugspurger
> <https://github.com/TomAugspurger> is doing in the PeriodArray PR?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/23093#issuecomment-429058284>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABQHIvUHbNjhgrix0AH8hvpdLlyX6KWQks5uj4dTgaJpZM4XXx8L>
> .
>
 But the question is then maybe: do we want to solve that before or after that PR (or in) ? # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23093?src=pr&el=h1) Report
> Merging [#23093](https://codecov.io/gh/pandas-dev/pandas/pull/23093?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/c8ce3d01e9ffafc24c6f9dd568cd9eb7e42c610c?src=pr&el=desc) will **increase** coverage by `0.01%`.
> The diff coverage is `93.54%`.

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

```diff
@@            Coverage Diff             @@
##           master   #23093      +/-   ##
==========================================
+ Coverage    92.2%   92.21%   +0.01%     
==========================================
  Files         169      169              
  Lines       50924    50920       -4     
==========================================
+ Hits        46952    46955       +3     
+ Misses       3972     3965       -7
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.63% <90.32%> (+0.01%)` | :arrow_up: |
| #single | `42.3% <58.06%> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/23093?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/core/indexes/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9kYXRldGltZXMucHk=) | `95.72% <ø> (-0.02%)` | :arrow_down: |
| [pandas/core/arrays/period.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL3BlcmlvZC5weQ==) | `94.29% <100%> (+1.43%)` | :arrow_up: |
| [pandas/core/indexes/period.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvaW5kZXhlcy9wZXJpb2QucHk=) | `93.43% <100%> (-0.02%)` | :arrow_down: |
| [pandas/io/pytables.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2lvL3B5dGFibGVzLnB5) | `92.44% <100%> (ø)` | :arrow_up: |
| [pandas/core/arrays/datetimes.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL2RhdGV0aW1lcy5weQ==) | `96.94% <100%> (+0.02%)` | :arrow_up: |
| [pandas/core/arrays/timedeltas.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL3RpbWVkZWx0YXMucHk=) | `93.96% <66.66%> (+1.43%)` | :arrow_up: |
| [pandas/core/arrays/datetimelike.py](https://codecov.io/gh/pandas-dev/pandas/pull/23093/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL2RhdGV0aW1lbGlrZS5weQ==) | `95.41% <90%> (-0.15%)` | :arrow_down: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/23093?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/23093?src=pr&el=footer). Last update [c8ce3d0...04c75ca](https://codecov.io/gh/pandas-dev/pandas/pull/23093?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 Fully agree on the proposed `_simple_new` interface.

> Closely related, what do we want out of _shallow_copy and
_shallow_copy_with_infer? In what ways do they differ from a
return self._simple_new(self.values, name=self.name)? Do they need to accept a
values argument?

We have been discussing those in https://github.com/pandas-dev/pandas/pull/22961 as well > All _attributes that we previously carried around on the instance would go on the Array. This would make _simple_new truly simple

I like this idea.

> pd.PeriodIndex(idx, start='foo')

Given that we have an opportunity to start fresh with the EA subclasses, I think we should avoid letting this happen there.  In the Index subclasses it would be nice to fix, but can be considered separately.

> Closely related, what do we want out of _shallow_copy and
_shallow_copy_with_infer?

Part of my takeaway from #23095 is that moving away from both of these would be helpful medium-term.
 I'm hopeful that we're close to a consensus here and in #23095 (and tangentially related #23031).  If not, is there a non-controversial subset of this that can be broken off?  These are blockers. note there is a bug out there about deserialization of HDF5 Period types. This may solve it > Why isn't this from_ordinals?

No idea what was originally intended; I want to go the other way with it and use a public constructor (i.e. `__new__`) ok this looks fine.