DEPR: deprecate msgpack support by jreback · Pull Request #27103 · pandas-dev/pandas (original) (raw)

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 andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Conversation8 Commits3 Checks0 Files changed

Conversation

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters

[ Show hidden characters]({{ revealButtonHref }})

jreback

jbrockmendel

jbrockmendel

jorisvandenbossche

@@ -92,6 +91,12 @@ def to_msgpack(path_or_buf, *args, **kwargs):
compress : type of compressor (zlib or blosc), default to None (no
compression)
"""
warnings.warn("The read_msgpack is deprecated and will be removed in a "

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

warnings.warn("The read_msgpack is deprecated and will be removed in a "
warnings.warn("The to_msgpack is deprecated and will be removed in a "
"future version.\n"
"It is recommended to use pyarrow for on-the-wire "
"transmission of pandas objects.",
FutureWarning, stacklevel=2)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this probably needs to be a stacklevel of 3 (since it is called from DataFrame.to_msgpack)

@jbrockmendel

I’m generally on board with this, but concerned about the fact that msgpack uses internals, so if this becomes “downstream” then that may make it harder to simplify things in internals if we are worried about breaking downstream.

@jreback

I’m generally on board with this, but concerned about the fact that msgpack uses internals, so if this becomes “downstream” then that may make it harder to simplify things in internals if we are worried about breaking downstream.

that’s all the more reason to deprecate this actually.