amol- commented on a change in pull request #11076:
URL: https://github.com/apache/arrow/pull/11076#discussion_r713187369
##########
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 supported deques just because we already support them in non nested
situation. My goal was to keep the same support for nested and non-nested
cases. Otherwise it seemed odd that we support `deque([1, 2, 3])` but not
`[deque([1, 2, 3])]`
If you notice, `deque` as a type was already in the
`parametrize_with_iterable_types` that our tests use to verify we support that
container
--
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: github-unsubscr...@arrow.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
