pitrou commented on a change in pull request #11076:
URL: https://github.com/apache/arrow/pull/11076#discussion_r713201315
##########
File path: cpp/src/arrow/python/inference.cc
##########
@@ -354,12 +365,15 @@ class TypeInferrer {
*keep_going = make_unions_;
} else if (PyArray_CheckAnyScalarExact(obj)) {
RETURN_NOT_OK(VisitDType(PyArray_DescrFromScalar(obj), keep_going));
- } else if (PyList_Check(obj)) {
- RETURN_NOT_OK(VisitList(obj, keep_going));
+ } else if (PySet_Check(obj) || (Py_TYPE(obj) == &PyDictValues_Type)) {
+ RETURN_NOT_OK(VisitSet(obj, keep_going));
} else if (PyArray_Check(obj)) {
RETURN_NOT_OK(VisitNdarray(obj, keep_going));
} else if (PyDict_Check(obj)) {
RETURN_NOT_OK(VisitDict(obj));
+ } else if (PyList_Check(obj) || PyTuple_Check(obj) ||
+ PyObject_IsInstance(obj, deque_type_.obj())) {
Review comment:
I think the idea is that we support generic iterables as top-level
input, so that you can for example call `pa.array` on a generator if you want
to generate data lazily. It makes little sense to allow the same flexibility
for inner values, though, such as values inside a list array.
```python
>>> pa.array((x for x in (1, 2, 3)))
<pyarrow.lib.Int64Array object at 0x7f44678606e0>
[
1,
2,
3
]
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]