GH-49384: [Python] Respect copy=True in ChunkedArray.__array__

[jingyi-zhao-01]

Rationale for this change

ChunkedArray.__array__(copy=True) should respect NumPy's copy request. For a single-chunk ChunkedArray, the current path can return a zero-copy read-only NumPy view instead.

Closes #49384.

What changes are included in this PR?

• Make ChunkedArray.__array__(copy=True) return a real NumPy copy.
• Add a regression test for the single-chunk case.

Are these changes tested?

Yes:

python -m pytest python/pyarrow/tests/test_table.py -q

Are there any user-facing changes?

Yes. np.array(pa.chunked_array([[...]]), copy=True) now returns a writable copied NumPy array, matching the behavior users expect from copy=True.

AI assistance

I used an codex while preparing this patch. I reviewed the change myself, kept it scoped to ChunkedArray.__array__, and verified it with the focused PyArrow table tests above.

• GitHub Issue: [Python] Single chunk ChunkedArray doesn't correctly respect copy in __array__method #49384

[github-actions]

Thanks for opening a pull request!

If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[github-actions]

⚠️ GitHub issue #49384 has been automatically assigned in GitHub to PR creator.

[raulcd]

@thisisnic this appears as merged but there's no commit and no changes, do you know what happened? Asking because it appears on GitHub UI as if merged by your user. I saw it before and was just chatting about it with @rok

[thisisnic]

Yeah, this is super weird. I didn't merge this myself. I had Claude run an analysis which sounds bizarre but plausible - will paste its explanation below - let me know if this sounds feasible.

---

The contributor (jingyi-zhao-01) opened this PR from their fork's main branch rather than a feature branch (i.e. jingyi-zhao-01:main → apache:main).

Here's the timeline:

1. July 18 08:32 — PR GH-49384: [Python] Respect copy=True in ChunkedArray.__array__ #50541 is opened
2. July 18 17:46 — pull[bot] force-pushes the contributor's fork main to sync with apache/main, overwriting their changes. After this, the PR has 0 commits, 0 additions, 0 deletions, 0 changed files.
3. July 19 23:45:24 — I merge my own PR GH-50496: [R] Polish NEWS.md for 25.0.0 #50497 (NEWS polish), which advances apache/main
4. July 19 23:45:26 — 2 seconds later, GitHub detects that the PR's head SHA (now identical to upstream main after the pull[bot] sync) is fully contained in the base branch, and auto-marks GH-49384: [Python] Respect copy=True in ChunkedArray.__array__ #50541 as "merged", attributing it to me since my merge was what triggered the detection

So the actual ChunkedArray.__array__(copy=True) fix was never landed — the PR was empty by the time it was closed. Issue #49384 should be reopened.

[raulcd]

I agree this seems like a wrong rebase on main and no commit landed on main. The GitHub UI was just confusing showing it as merged and adding your user but the reasoning sounds plausible. Thanks for taking a look. @jingyi-zhao-01 feel free to submit a new PR, I've manually re-opened the issue.

[jingyi-zhao-01]

@raulcd got it i will open a feature branch on my forked repo

[jingyi-zhao-01]

Opened a new feature-branch PR here: #50561. This one contains the same scoped fix plus the regression test.