ENH: ExtensionArray.unique
This doesn't conflict with https://github.com/pandas-dev/pandas/pull/19863 since unique returns an ExtensionArray. # [Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/19869?src=pr&el=h1) Report
> Merging [#19869](https://codecov.io/gh/pandas-dev/pandas/pull/19869?src=pr&el=desc) into [master](https://codecov.io/gh/pandas-dev/pandas/commit/bfe6ebcb0791e0de06e70cf2dd91129bbacf583d?src=pr&el=desc) will **increase** coverage by `<.01%`.
> The diff coverage is `100%`.

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

```diff
@@            Coverage Diff             @@
##           master   #19869      +/-   ##
==========================================
+ Coverage    91.7%    91.7%   +<.01%     
==========================================
  Files         150      150              
  Lines       49165    49168       +3     
==========================================
+ Hits        45087    45090       +3     
  Misses       4078     4078
```

| Flag | Coverage Δ | |
|---|---|---|
| #multiple | `90.09% <100%> (ø)` | :arrow_up: |
| #single | `41.86% <50%> (ø)` | :arrow_up: |

| [Impacted Files](https://codecov.io/gh/pandas-dev/pandas/pull/19869?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [pandas/core/algorithms.py](https://codecov.io/gh/pandas-dev/pandas/pull/19869/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYWxnb3JpdGhtcy5weQ==) | `94.17% <100%> (-0.01%)` | :arrow_down: |
| [pandas/core/arrays/base.py](https://codecov.io/gh/pandas-dev/pandas/pull/19869/diff?src=pr&el=tree#diff-cGFuZGFzL2NvcmUvYXJyYXlzL2Jhc2UucHk=) | `76.74% <100%> (+2.38%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/pandas-dev/pandas/pull/19869?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/19869?src=pr&el=footer). Last update [bfe6ebc...41dd128](https://codecov.io/gh/pandas-dev/pandas/pull/19869?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).
 @TomAugspurger before we move on, some 32-bit issues: https://travis-ci.org/MacPython/pandas-wheels/jobs/345517480

```
    def test_loc_frame(self, data):
        df = pd.DataFrame({"A": data, 'B': np.arange(len(data))})
        expected = pd.DataFrame({"A": data[:4]})
```
in pandas/tests/extension/base/getitem.py

you need to pass ``dtype='int64'`` when using ``np.arange`` Thanks.

Do you get email alerts for the build in MacPython/pandas-wheels? I don't see anywhere to sign up for them.

Can you take a look at my maybe-fix for the test failures? IIUC the issue was that the `DecimalArray` does an `np.ndarray.take(indexer)`. NumPy expected `indexer.dtype` to be `np.intp` on that system, but from pandas it'll always be `np.int64`? yes i'll put up a fix. to get alerts you have to go to travis ci profile (yours), sync github then check the box on that repo, then wait a while :> I added `_constructor`, but I think it and the old way of doing `type(self)(arg)` were a mistake. 
https://github.com/pandas-dev/pandas/issues/19906 I added a comment saying we should have a better reason (and specify this in the docs, as now it doesn't say this) for adding something like `_constructor`, but now I see the new issue you opened, and this is actually good reason :) 
As I was previously complaining for geopandas that the requirement that `GeometryArray()` should be able to take a sequence of scalars was a bit annoying (but certainly hackable). But this way we could indeed keep the main constructor more free to the extension author. 👍  FWIW, this PR is blocking factorize (and this groupby) so I just want to get this one merged 😆 

A concrete example in https://github.com/pandas-dev/pandas/issues/19906 would be very helpful. To move forward quickly with this PR, I would personally just leave it as `type(self)(..)` for now, as that is perfectly valid code and more conservative with regard to extending the interface. 
And keep potentially adding `_constructor` (or variants proposed in https://github.com/pandas-dev/pandas/issues/19906) for another PR, where we could discuss in more detail what is *exactly* expected from such constructor. OK, reverted.

If we get #19906 sketched out I can implement it later today, so we'll only have the `type(self)(...)` stuff in master for a day or two. thanks!