Skip to content

CI: Unpin pyarrow<10 #50314

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

Merged
merged 3 commits into from
Dec 24, 2022
Merged

CI: Unpin pyarrow<10 #50314

merged 3 commits into from
Dec 24, 2022

Conversation

phofl
Copy link
Member

@phofl phofl commented Dec 17, 2022

@phofl phofl requested a review from MarcoGorelli December 17, 2022 15:32
@phofl phofl added CI Continuous Integration Dependencies Required and optional dependencies labels Dec 17, 2022
with pytest.raises(TypeError, match="different 'freq'"):
pa.array(periods, type=ArrowPeriodType("T"))
else:
result = pa.array(periods, type=ArrowPeriodType("T"))
Copy link
Member

Choose a reason for hiding this comment

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

do you know why this started working?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not really, no

Copy link
Member

Choose a reason for hiding this comment

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

OK, it's probably better if someone familiar with pyarrow reviews this. I don't see why a Int64array is returned after passing type ArrowPeriodType, nor why the freq doesn't seem to make a difference

(Pdb) pa.array(periods, type=ArrowPeriodType("T"))
<pyarrow.lib.Int64Array object at 0x7fb99f3aab80>
[
  17167,
  17168,
  17169
]
(Pdb) pa.array(periods, type=ArrowPeriodType("M"))
<pyarrow.lib.Int64Array object at 0x7fb99f3aaa60>
[
  17167,
  17168,
  17169
]
(Pdb) pa.array(periods, type=ArrowPeriodType("fdafsdfas"))
<pyarrow.lib.Int64Array object at 0x7fb99f3aaa00>
[
  17167,
  17168,
  17169
]

but it's probably my lack of familiarity

Copy link
Member

Choose a reason for hiding this comment

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

I think would still expect this to fail if converting to another freq used to fail cc @jorisvandenbossche

Copy link
Member

Choose a reason for hiding this comment

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

Ah, that seems an oversight in a recent improvement to allow specifying extension types in pa.array(..) (so specifically when passing objects that define __arrow_array__, we ignore the user specified type ..).

(sidenote: we should really try to catch such issues before releasing .. We never tested against the nightly conda/wheel package of pyarrow?)

About failing to cast: I am not sure that is possible / easy (without adding some mechanism to let the extension type control the cast behaviour). How it works right now (once fixed) is that the input is first cast to the extension type's storage type (in this case int64), and then the extension array is constructor from that storage.
Which doesn't make sense here in the case of two different period freqs, so that's clearly a sign we need to make this "smarter" somehow.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for the explanation. Marked test as xfail for now

Copy link
Member

@MarcoGorelli MarcoGorelli left a comment

Choose a reason for hiding this comment

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

xfailing looks fine to me

Copy link
Member

@mroeschke mroeschke left a comment

Choose a reason for hiding this comment

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

LGTM. Should this be backported?

@phofl
Copy link
Member Author

phofl commented Dec 23, 2022

no opinion, could do but don't have to I think

@mroeschke mroeschke added this to the 2.0 milestone Dec 24, 2022
@mroeschke mroeschke merged commit 4878dfe into pandas-dev:main Dec 24, 2022
@mroeschke
Copy link
Member

Thanks @phofl

@phofl phofl deleted the revert_pyarrow_pin branch December 28, 2022 19:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI Continuous Integration Dependencies Required and optional dependencies
Projects
None yet
Development

Successfully merging this pull request may close these issues.

CI: pyarrow 10 broke our ci
4 participants