Feature Type
-
[ ] Adding new functionality to pandas
-
[ ] Changing existing functionality in pandas
-
[X] Removing existing functionality in pandas
Problem Description
This comment on the python discussion is interesting: https://discuss.python.org/t/name-suggestions-for-attributeerrors-and-possibly-nameerrors-should-not-include-names-with-single-leading-underscores/48588
Example code (from main):
>>> pd.DataFrame.append()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: type object 'DataFrame' has no attribute 'append'. Did you mean: '_append'?
What is happening is that the python interpreter is suggesting people use DataFrame._append()
since we removed append()
Feature Description
I think if we renamed the internal _append()
to something like _internal_append_do_not_use()
then maybe the interpreter wouldn't do that suggestion.
Alternative Solutions
Bring back DataFrame.append()
???
Additional Context
No response
Comment From: rhshadrach
Is the proposal to do this with all internal methods that are similar to removed external names? I'm pretty opposed here - I think we should be free to chose internal names however we see fit.
Comment From: Dr-Irv
Is the proposal to do this with all internal methods that are similar to removed external names? I'm pretty opposed here - I think we should be free to chose internal names however we see fit.
No, but in this case, since we deprecated DataFrame.append()
, we don't want people using DataFrame._append()
as a workaround so we need to hide it better.
Comment From: asishm
~~I'd me somewhat +1 - see this SO answer -https://stackoverflow.com/a/76449334/2214597 while it does have a disclaimer, it's still pretty heavily upvoted.~~
Nvm - this SO question is already mentioned in the Discourse thread
Comment From: mroeschke
I would definitely wait until https://github.com/python/cpython/issues/116871 has a resolution upstream before preemptively acting here.
Comment From: jbrockmendel
Isn’t a fix in cpython going to take ages? I’d be fine with changing the name on our end
Comment From: rhshadrach
No opposition if this is a unique case, but I'd like to not play whack-a-mole with the CPython interpreter and our internal names. That seems like too much code churn to me.
Comment From: Dr-Irv
No opposition if this is a unique case, but I'd like to not play whack-a-mole with the CPython interpreter and our internal names. That seems like too much code churn to me.
I think the issue here is that we used to have DataFrame.append()
, and now CPython is suggesting DataFrame._append()
, so people are using it. If we remove methods in the future, then we should be aware of the similarity of the removed name with any "private" methods.
Comment From: WillAyd
I'd also be fine with changing the name internally. Agree with @jbrockmendel we will be waiting a long time for the fix to make its way through different versions of Python.
There will be some breakage if people have decided to use this, but the longer we wait the worse that handcuff becomes
Comment From: rhshadrach
I'm fine doing it in this case, but maintain my opposition if more cases start popping up.