Skip to content

String dtype: turn on by default #61722

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

jorisvandenbossche
Copy link
Member

@jorisvandenbossche jorisvandenbossche commented Jun 27, 2025

Now that 2.3.0 is released, time to switch the default on main to prepare for a 3.0 release (and also such that people using nightlies get this)

I assume this might also still uncover some failing tests. And the docstrings will still fail for sure.

@jorisvandenbossche jorisvandenbossche added this to the 3.0 milestone Jun 27, 2025
@jorisvandenbossche jorisvandenbossche added the Strings String extension data type and string data label Jun 27, 2025
@jorisvandenbossche
Copy link
Member Author

cc @rhshadrach I remember you gave the feedback when CoW option was removed (actually removed, without ability to turn CoW off), that it might be good to keep the option working for some time? (so that if you run into issues, you can still turn it off temporarily)

Shall we do that here?

And if we do that:

  • do we want to keep some CI testing that? (for example I could keep the build currently testing turning it on, but then with turning it off)
  • add a warning for people setting the option to False that this is only kept working temporarily?

@jorisvandenbossche
Copy link
Member Author

Aside docstrings, the only tests that were failing are the ones with the minimum pyarrow dependency of 10.0.1. For our support window of 2 years, we can bump that to 12.0.1. If that helps, will move it to a separate PR.

@mroeschke
Copy link
Member

Shall we do that here?

I would like to keep the option for users to switch back to the old string type if needed

@jbrockmendel
Copy link
Member

Any idea how many xfailed tests are specific to this? I saw some this morning, will see if I can address those.

@jbrockmendel
Copy link
Member

looks like 20 tests (76 with parametrization) are xfailed. At least some of these will be easy-but-tedious of updating expecteds that I'll get out of the way now. I don't see any reason why these would be a blocker for this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Strings String extension data type and string data
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants