[
https://issues.apache.org/jira/browse/ARROW-5566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17181437#comment-17181437
]
Andrew Wieteska commented on ARROW-5566:
----------------------------------------
This works fine on 1.0:
{code:java}
In [8]: pa.array([np.float32(3), np.nan])
Out[8]:
<pyarrow.lib.DoubleArray object at 0x7f0459732fa0>
[
3,
nan
]
{code}
We also already test for this in pyarrow/tests/test_array.py. The
pa.array(['string', np.nan]) case was handled in ARROW-6227.
I think we can close this
> [Python] Overhaul type unification from Python sequence in
> arrow::py::InferArrowType
> ------------------------------------------------------------------------------------
>
> Key: ARROW-5566
> URL: https://issues.apache.org/jira/browse/ARROW-5566
> Project: Apache Arrow
> Issue Type: Improvement
> Components: Python
> Reporter: Wes McKinney
> Priority: Major
>
> I'm working on ARROW-4324 and there's some technical debt lying in
> arrow/python/inference.cc because the case where NumPy scalars are mixed with
> non-NumPy Python scalar values, all hell breaks loose. In particular, the
> innocuous {{numpy.nan}} is a Python float, not a NumPy float64, so the
> sequence {{[np.float16(1.5), np.nan]}} can be converted incorrectly.
> Part of what's messy is that NumPy dtype unification is split from general
> type unification. This should all be combined together with the NumPy types
> mapping onto an intermediate value (for unification purposes) that then maps
> ultimately onto an Arrow type
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
