GH-36809: [Python] MapScalar.as_py with custom field name

[0x26res]

Rationale for this change

MapScalar.as_py doesn't take into account custom key/value field names

What changes are included in this PR?

Fix and tests

Are these changes tested?

Simple unit test

Are there any user-facing changes?

No API changes.

• Closes: [Python] KeyError in MapScalar with custom field name #36809

[github-actions]

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

[kou]

Could you revert updating submodules?
It seems that we don't need them.

[0x26res]

Could you revert updating submodules? It seems that we don't need them.

I agree, I didn't intend to do that. Do you know which git command I need to run to revert them?

[kou]

The following command lines will work:

cd cpp/submodules/parquet-testing
git checkout b2e7cc755159196e3a068c8594f7acbaecfdaaac
cd -
cd testing
git checkout 47f7b56b25683202c1fd957668e13f2abafc0f12
cd -
git add cpp/submodules/parquet-testing testing
git commit
git push

[0x26res]

That worked, thanks 👍

[0x26res]

@kou do you mind reviewing again? Thanks.

[kou]

+1

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 6 benchmarking runs that have been run so far on merge-commit 52ac718.

There was 1 benchmark result indicating a performance regression:

• Commit Run on arm64-m6g-linux-compute at 2023-07-26 15:05:52Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-14, scale_factor=10

The full Conbench report has more details. It also includes information about possible false positives for unstable benchmarks that are known to sometimes produce them.