API: remove deep keyword from EA.copy #27083
Conversation
There was a problem hiding this comment.
I would be ok with just making this change (no deprecation cycle), @jorisvandenbossche
| @@ -101,10 +101,8 @@ def take(self, indexer, allow_fill=False, fill_value=None): | |||
| allow_fill=allow_fill) | |||
| return self._from_sequence(result) | |||
|
|
|||
| def copy(self, deep=False): | |||
There was a problem hiding this comment.
can you add a test in the pandas/tests/extension/constructors.py so it hits all EA's (for view & copy)
jreback
added
API Design
ExtensionArray
jorisvandenbossche
changed the title
|
Looks good to me. As usual (sorry ...), I would only add |
pandas/core/arrays/base.py
Outdated
| """ | ||
| raise AbstractMethodError(self) | ||
|
|
||
| def view(self, dtype=None) -> ABCExtensionArray: |
There was a problem hiding this comment.
ok with .view() @jorisvandenbossche @TomAugspurger ?
There was a problem hiding this comment.
actually let's remove this for now @jbrockmendel
There was a problem hiding this comment.
@jbrockmendel can you add a whatsnew note that remove the deep kwarg for EA
So a user only runs into this when they directly interface with an ExtensionArray themselves (as the uses within pandas get fixed). Further, for EA authors only implementing the EA itself, it's not a backwards incompatible change, as we don't have a problem that the EA still has the keyword, it will just never be called from inside pandas. It seems that users doing |
|
Sounds good.
…On Thu, Jun 27, 2019 at 3:04 PM Joris Van den Bossche < ***@***.***> wrote:
Slight preference for deprecation, but don't have strong thoughts here.
So a user only runs into this when they directly interface with an
ExtensionArray themselves (as the uses within pandas get fixed). Further,
for EA authors only implementing the EA itself, it's not a backwards
incompatible change, as we don't have a problem that the EA still has the
keyword, it will just never be called from inside pandas.
It seems that users doing Series.array.copy(deep=True) is something very
specific, and also only introduced very recently (eg Categorical is longest
out there, but has actually no copy keyword). IntegerArray and
IntervalArray eg does have one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#27083?email_source=notifications&email_token=AAKAOIXCWW7BQBAYLMGNM3TP4UMMZA5CNFSM4H37CG42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYYG4YY#issuecomment-506490467>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAKAOIVQTC74QUOSYMYYFRTP4UMMZANCNFSM4H37CG4Q>
.
|
| values = self.sp_values | ||
|
|
||
| def copy(self): | ||
| values = self.sp_values.copy() | ||
| return self._simple_new(values, self.sp_index, self.dtype) |
There was a problem hiding this comment.
@TomAugspurger do we need to copy the index here?
There was a problem hiding this comment.
Not really sure. I don't know if they're designed for sharing across instances, or whether we mutate them inplace.
There was a problem hiding this comment.
In any case in sparse.py, we don't mutate them inplace. I would also assume it is fine not to copy them.
|
lgtm. ping on green. |
|
Thanks! |
Not clear on what type of deprecation cycle we want here