Skip to content

DEPR: keep_default_dates and convert_dates in read_json #59349

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

Closed
wants to merge 1 commit into from

Conversation

phershbe
Copy link
Contributor

Issue #59161

(NOT TOTALLY DONE THIS IS A DRAFT PULL REQUEST ... THE DESCRIPTION WILL BE DONE IN PROFESSIONAL LANGUAGE IF I CAN GET TO THE ACTUAL PULL REQUEST)

New contributor and self-taught non-professional programmer who loves pandas and fixed a few tests here in 2022.

The part not finished yet = refactoring dtype conversion to use infer_dtype instead of astype guessing ... reading the directions closely enough to get the development environment built correctly took a while and then I've made quite a few changes and am a little bit confused about the aforementioned part and was hoping to get the other changes checked in order to make sure that I am on the correct path.

I tried to delete instances of keep_default_dates and convert_dates in parameters, calls, and corresponding tests of read_json and in related functions, so that it will fall back on using dtype conversions from the ujson parser, while keeping the functions and tests intact whenever they are not totally dependent on keep_default_dates and convert_dates.

convert_dates also exists in a file for sas7bdat and in parts of the code involving Stata, but not as part of the read_json function in such cases, so I am pretty sure that these are separate but I wanted to check.

@jorisvandenbossche
Copy link
Member

Apologies for the lack of review, but one quick feedback item: when deprecating something, we initially need to keep the functionality working (but with raising a warning when the user specifies the keyword), and the actual code only gets removed in a later stage (in the next major release).

@phershbe
Copy link
Contributor Author

No problem, thank you for the message. I unassigned myself on the issue and wrote a message explaining it, it might be a little bit too high for my current level and I don't want to keep it blocked. I will check out old pull requests for deprecations following your feedback.

@mroeschke
Copy link
Member

Thanks for the PR but it appears to have gone stale. Going to close but please let us know if you'd like to continue here

@mroeschke mroeschke closed this Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants