Skip to content

INTPYTHON-520 Ensure all parquet data types are handled #338

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

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

Conversation

sleepyStick
Copy link

@sleepyStick sleepyStick commented Jul 25, 2025

I think this is what we want???
edit: docs will be completed via a docs ticket but in general the only parquet types that we don't inherently already support are on the left and what they can be converted to (that we do support) are on the right.

  • uint8 -> pa.int32
  • uint16 -> pa.int32
  • uint32 -> pa.int64
  • uint64 -> pa.int64
  • int8 -> pa.int32
  • int16 -> pa.int32
  • float16 -> pa.float64
  • float32 -> pa.float64
  • float64 -> pa.float64
  • timedelta -> pa.int64

@sleepyStick
Copy link
Author

3.13t tests are failing because pandas (which I import for the test) isn't installed..is that something i need to fix here?

@blink1073
Copy link
Member

3.13t tests are failing because pandas (which I import for the test) isn't installed..is that something i need to fix here?

The tests are run with and without optional deps (polars and pandas), so they need to have a skip condition when pandas isn't installed.

@blink1073
Copy link
Member

Hmm, do we want to offer a "best effort" conversion mode where we automatically make these conversions in write()?

@sleepyStick
Copy link
Author

Hmm, do we want to offer a "best effort" conversion mode where we automatically make these conversions in write()?

hmm would that look like adding an optional parameter to write? where if we do best effort conversion unless specified (via the parameter)?
(to be clear, all for the idea, just wanna make sure i'm envisioning it the same way as you? and if not, to see what the differences are)

@blink1073
Copy link
Member

I see it as similar to allow_invalid in aggregate_polars_all and friends. It would be a single flag that would convert unsupported types to supported ones.

@sleepyStick sleepyStick marked this pull request as ready for review July 28, 2025 22:26
@sleepyStick sleepyStick requested a review from a team as a code owner July 28, 2025 22:26
@sleepyStick sleepyStick requested a review from blink1073 July 28, 2025 22:27
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.

2 participants