-
-
Notifications
You must be signed in to change notification settings - Fork 18.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API: consistent __array__ for datetime-like ExtensionArrays #23593
API: consistent __array__ for datetime-like ExtensionArrays #23593
Conversation
Hello @jorisvandenbossche! Thanks for updating the PR. Cheers ! There are no PEP8 issues in this Pull Request. 🍻 Comment last updated on January 05, 2019 at 20:26 Hours UTC |
isort failure:
|
Yeah, I will still need to get used to it :-) |
I have for dask-ml. I'm experimenting with it in pandas today.
I'll open an issue suggesting that for the docs if it works well. |
Codecov Report
@@ Coverage Diff @@
## master #23593 +/- ##
==========================================
+ Coverage 92.37% 92.38% +<.01%
==========================================
Files 166 166
Lines 52379 52377 -2
==========================================
Hits 48386 48386
+ Misses 3993 3991 -2
Continue to review full report at Codecov.
|
@@ -126,6 +126,24 @@ def test_int_properties(self, datetime_index, propname): | |||
|
|||
tm.assert_numpy_array_equal(result, expected) | |||
|
|||
def test_array(self, datetime_index): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
while you're at it, can you make sure there are analogous tests for the DTI/TDI/PI index classes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I only have to see then a bit how that overlaps with your PR then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if there are any existing tests on this somewhere (for the index classes)? Not directly finding something
Implement view while at it? |
On EAs? Is there a reason to do that? |
IIRC from other branches we'll need to do it eventually. Since I don't have the precise reason on hand, it's reasonable to wait until actually needed. |
From #23569 (comment) You questioned whether we should implement I'm not really clear what's best here. Do we publicly document exactly what an ordinal is, beyond just saying that it's an integer (though maybe that's enough justify making |
@jbrockmendel can you rebase this. |
This one is from Joris :) |
ok then @jorisvandenbossche lgtm. |
d77b823
to
8c68e2a
Compare
@jorisvandenbossche can you rebase |
Fixed the linting error. But, we still need to decide on #23593 (comment): should
I don't really care that much. If "power users" want to work with the integers, I think the |
Sounds good to me.
…On Fri, Nov 23, 2018 at 4:53 AM Joris Van den Bossche < ***@***.***> wrote:
Fixed the linting error.
But, we still need to decide on #23593 (comment)
<#23593 (comment)>:
should np.array(period_array, dtype='int') work?
PeriodIndex currently does this (but also without making a copy, which I
think we should change to conform to numpy behaviour).
I'm not really clear what's best here. Do we publicly document exactly
what an ordinal is, beyond just saying that it's an integer (though maybe
that's enough justify making int)?
I don't really care that much. If "power users" want to work with the
integers, I think the asi8 attribute is more explicit to use? (and is
already public)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#23593 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHItg6Sd05Rh7_p7EkVCv2N2HuOThlks5ux9OlgaJpZM4YWVyz>
.
|
yeah this is ok |
need to merge master on this |
@jorisvandenbossche @TomAugspurger @jbrockmendel should rebase this and see where things are. |
@jorisvandenbossche can you merge master |
@jreback any other comments? @TomAugspurger fine to merge this? There is some overlap with your other PR on |
Yep, this is fine. I'd prefer this goes in first. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see my comments
# used for Timedelta/DatetimeArray, overwritten by PeriodArray | ||
if is_object_dtype(dtype): | ||
return np.array(list(self), dtype=object) | ||
return self._data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would raise if dtype not in [None, object]
Why? Eg for Datetime/TimedeltaArray, now |
outside of the specified dtypes, you must raise for a dtype if you are not passing to but this is really easy to answer. provide tests that use non-valid dtypes and show that it raises. |
This is already tested for PeriodArray: https://github.com/pandas-dev/pandas/pull/23593/files#diff-fff2a1331dd7864425d7581505b95e58R622 |
And that can't be a base test since we don't know what is and isn't valid for subtypes. Agreed with @jorisvandenbossche that NumPy should handle the exception raising if the values aren't valid for the requested dtype. |
can you merge master |
…e-ea-array-protocol
Merged master and
|
thanks @jorisvandenbossche and @TomAugspurger |
closes #23569
Already makes the
__array__
for the datetimelike EAs consistent with each other and with Series/Index (for the default case of not specifying a dtype)