-
-
Notifications
You must be signed in to change notification settings - Fork 18.2k
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
DEPR: remove pandas.core.common is_* #19769
Conversation
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.
Sorry I forgot about #19304
doc/source/whatsnew/v0.23.0.txt
Outdated
@@ -624,6 +624,7 @@ Removal of prior version deprecations/changes | |||
- The modules `pandas.tools.hashing` and `pandas.util.hashing` have been removed (:issue:`16223`) | |||
- The top-level functions ``pd.rolling_*``, ``pd.expanding_*`` and ``pd.ewm*`` have been removed (Deprecated since v0.18). | |||
Instead, use the DataFrame/Series methods :attr:`~DataFrame.rolling`, :attr:`~DataFrame.expanding` and :attr:`~DataFrame.ewm` (:issue:`18723`) | |||
- Imports from ``pandas.core.common`` for api like functions such as ``is_datetime64_dtype`` are now removed. These are located in ``pandas.api.types``. Furthermore, errors are removed as well from ``pandas.core.common`` and are available in ``pandas.errors`` (:issue:`13990`) |
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.
Can remove "for api" and just have "functions like is_datetime64_dtype."
And using the errors here didn't actually emit deprecation warnings did it? Those should be deprecated before removing.
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.
no, we simply have to remove them. these are classes and we were never able to actually deprecate them.
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.
You can deprecate pretty easily with subclassing
class PerformanceWarning(pandas.errors.PerformanceWarning):
def __init__(self, *args, **kwargs):
warnings.warn('Deprecated. Use pandas.errors instead', FutureWarning)
super().__init__(*args, **kwargs)
could meta-program that if you want, but it's just 4 errors.
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 believe @jorisvandenbossche tried this, and we had a discussion about this in the original issue.
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.
The problem we discussed AFAIR was about the problem people importing an error to then only catch it. That way the error is never 'called', and a deprecation warning like the above would not work.
It does work for raising such a warning (but I think catching will be more common).
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 think the only way this can really be solved is by renaming core/common.py
to eg core/utils.py
, and then you can deprecate the whole core/common.py
module, and already raise warning on importing it.
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.
Could override isinstancecheck? Probably overkill.
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.
yeah I think we had this discussion a while back, and it looks like it can be done, but then the details kill us. @jorisvandenbossche soln would work, but I think will just put a big warning.
Ah, I see.
In that cause, probably best to just remove. I would split that off into
it's own subitem in the release notes though (we could also add it to
pandas_compat, right?).
…On Mon, Feb 19, 2018 at 2:35 PM, Joris Van den Bossche < ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In doc/source/whatsnew/v0.23.0.txt
<#19769 (comment)>:
> @@ -624,6 +624,7 @@ Removal of prior version deprecations/changes
- The modules `pandas.tools.hashing` and `pandas.util.hashing` have been removed (:issue:`16223`)
- The top-level functions ``pd.rolling_*``, ``pd.expanding_*`` and ``pd.ewm*`` have been removed (Deprecated since v0.18).
Instead, use the DataFrame/Series methods :attr:`~DataFrame.rolling`, :attr:`~DataFrame.expanding` and :attr:`~DataFrame.ewm` (:issue:`18723`)
+- Imports from ``pandas.core.common`` for api like functions such as ``is_datetime64_dtype`` are now removed. These are located in ``pandas.api.types``. Furthermore, errors are removed as well from ``pandas.core.common`` and are available in ``pandas.errors`` (:issue:`13990`)
I think the only way this can really be solved is by renaming
core/common.py to eg core/utils.py, and then you can deprecate the whole
core/common.py module, and already raise warning on importing it.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#19769 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABQHIrRypQg_tMPT3DGCGcQi0w5F1Mojks5tWdslgaJpZM4SK5Eh>
.
|
Codecov Report
@@ Coverage Diff @@
## master #19769 +/- ##
==========================================
- Coverage 91.61% 91.57% -0.05%
==========================================
Files 150 150
Lines 48887 48865 -22
==========================================
- Hits 44786 44746 -40
- Misses 4101 4119 +18
Continue to review full report at Codecov.
|
xref #13990
xref #19304